Autonomous software engineer
How to use
Devin.
Investigating codebases, implementing scoped engineering tasks, producing pull requests, and standardizing repeatable work with Knowledge and Playbooks.
Devin is a autonomous AI software engineering agent. Investigating codebases, implementing scoped engineering tasks, producing pull requests, and standardizing repeatable work with Knowledge and Playbooks. This guide covers the whole path in one place: official access, a first session that produces something reviewable, the checks that make output trustworthy, and the permissions worth limiting before you connect real work.
AI should make the work easier to inspect. If the workflow removes the source, the owner, or the review step, redesign the workflow.
Access & setup
Find, install, and sign in to Devin
Get into the official Devin experience with the right account and a setup you understand.
- 01
Start at https://devin.ai/ and confirm the domain before entering account or payment information.
- 02
Availability: Web application connected to indexed repositories and supported engineering integrations.
- 03
A Devin account or organization, authorized repository access, configured integrations, and a review process for code, secrets, and pull requests.
- 04
Sign in with the account you intend to keep using, then review plan, data, notification, and permission settings.
- 05
Run one low-risk test task before connecting sensitive files, repositories, or workspace data.
- Use official download pages.
- Review permissions during setup.
- Keep installers and applications updated.
First session
Your first useful Devin session
Learn the interaction loop using a small task with a clear outcome.
- 01
Index an authorized repository and confirm its default branch, instructions, integrations, and checks.
- 02
Begin in Ask mode with a small task, clear acceptance criteria, and the relevant repository context.
- 03
Review the proposed plan before starting an Agent session and state forbidden or approval-gated actions.
- 04
Inspect activity, final diff, test results, and Session Insights before merging anything.
- State the outcome before the background.
- Provide the real source material.
- Review the result before expanding the task.
Quality control
Check the quality of Devin output
Turn generated code into a change you would put your name on in review.
- 01
Restate the intended behaviour and the acceptance criteria before reading a single generated line.
- 02
Read the diff rather than the chat summary; the summary describes intent, the diff describes what actually changed.
- 03
Run the test suite, then write a test that would fail if the change were wrong, and confirm it passes for the right reason.
- 04
Check the edges the model tends to skip: error paths, null and empty cases, concurrency, and migration or rollback behaviour.
- 05
Trace every new dependency, network call, and file write, and confirm each one is genuinely required.
- Review the diff, never the description of the diff.
- A passing test suite proves the tests pass, not that the change is correct.
- Keep changes small enough that a human can actually review them.
Privacy & permissions
Use Devin safely
Give the tool enough repository access to help, and no more than that.
- 01
Decide what the tool may read and what it may write before connecting a repository.
- 02
Scope tokens and integrations to the narrowest repository, branch, and permission set that still works.
- 03
Keep secrets out of the context window: use environment variables and secret stores, never inline credentials.
- 04
Require review before generated code touches authentication, payments, permissions, migrations, or deletion paths.
- 05
Audit what the integration retained after the session, and revoke access that is no longer needed.
- Devin can use shells, browsers, secrets, integrations, and Git. Apply least privilege, scope sessions tightly, keep production actions human-approved, and review every code and dependency change.
- Follow your organisation's approved-use policy.
- Never treat fluent output as authorization to act.
Core workflows
Step-by-step ways to use Devin for the work it does best.
Each workflow below has its own outcome, steps and review checkpoints.
Move from repository question to reviewed pull request with explicit scope and checkpoints.
↓ 02 WorkflowCreate a reusable Devin PlaybookTurn a successful repeated workflow into a versioned procedure with clear inputs and postconditions.
↓Workflow 01
Run a controlled engineering session with Devin
Move from repository question to reviewed pull request with explicit scope and checkpoints.
Outcome: Complete a bounded code change whose implementation and validation your team understands.
- 01
Index the correct repository and inspect its branch, status, instructions, secrets, and standard checks.
- 02
Start in Ask mode to investigate the code and agree on acceptance criteria and a file-level plan.
- 03
Move to Agent mode only after the task is small enough, naming forbidden changes and required human approvals.
- 04
Monitor shell, browser, file, and Git activity, answering blockers without widening the assignment.
- 05
Review the diff, tests, security impact, dependencies, and Session Insights before merging the pull request.
What good use looks like
- Ask before Agent.
- Keep one objective per session.
- Never merge an unexplained diff.
Workflow 02
Create a reusable Devin Playbook
Turn a successful repeated workflow into a versioned procedure with clear inputs and postconditions.
Outcome: Help teammates reproduce a reliable Devin outcome without copying a vague mega-prompt.
- 01
Choose a repeated task with a known successful session and separate durable repository guidance into Knowledge.
- 02
Define the outcome, required user inputs, setup, procedure, specifications, forbidden actions, and delivery format.
- 03
Write imperative steps that cover setup through verification while leaving legitimate implementation choices open.
- 04
Test the Playbook on a low-risk example and compare its result, cost, interventions, and failure points with the original.
- 05
Publish with a unique macro, review version history, and revise it when dependencies or team practices change.
What good use looks like
- Use Knowledge for conventions.
- State postconditions precisely.
- Test every Playbook before team rollout.
Official references
Check the current product documentation.
Features, plan limits, availability, and data controls change. These official pages are the starting points used for this guide.