How to Migrate From Devin to Claude Code
Devin was the first AI software engineer built for long-horizon autonomous tasks: give it a ticket, it spins up a sandboxed environment, writes code, runs tests, and opens a pull request. For teams that want hands-off execution on clearly defined tasks, that model works. The friction shows up when the task is ambiguous, when you want to be in the loop on decisions, when Devin's isolated sandbox doesn't have access to your actual development environment, or when the per-task pricing is at odds with the volume of tasks you want to run.
Claude Code runs in your terminal, in your repository, with access to your file system and running processes. The model is collaborative rather than autonomous: you and the AI work through the code together, with you retaining control at each step. Devin optimizes for "assign and wait." Claude Code optimizes for "pair program with the AI." The teams moving between them are usually deciding which model fits their actual workflow better, and increasingly, whether Devin's pricing model makes sense for their task volume.
What's actually different
The execution environment is the most fundamental difference. Devin operates in its own sandboxed cloud environment. Claude Code operates in your local terminal, with your git repository, your environment variables, your running services.
| Dimension | Devin | Claude Code |
|---|---|---|
| Environment | Sandboxed cloud VM | Your local terminal / repository |
| Interaction model | Autonomous (you assign, it executes) | Collaborative (you direct, it executes) |
| Cost model | Per-task / subscription | Claude API usage tokens |
| Context mechanism | Task description | CLAUDE.md project conventions |
| Git integration | Opens PRs from sandbox | Operates directly in your repo |
| Tool access | Sandboxed tools | Your actual tools, commands, files |
| IDE integration | Devin web interface | Terminal + any editor |
| Oversight | Async check-ins | Real-time, every step |
The cost model difference is significant in practice. Devin's pricing is structured around sessions or tasks at a relatively high per-unit cost. Claude Code's cost is token-based, and many coding tasks at typical code complexity cost a fraction of a comparable Devin session. Teams running high volumes of moderate-complexity tasks find the economics shift substantially.
The CLAUDE.md convention deserves explanation. In Claude Code, you can create a CLAUDE.md file at the root of your repository that contains project-specific instructions: coding conventions, architectural decisions, which commands to run for testing, which patterns to prefer, which files to avoid. Claude Code reads this file when it starts and follows those conventions throughout the session. This is how you give Claude Code persistent project context without repeating yourself in every conversation.
Mapping your existing workflows
The Devin-to-Claude Code migration isn't a node-for-node translation like automation tool migrations. It's more of a workflow and interaction pattern shift.
Devin "session" (assign a task, wait for completion) maps to a Claude Code conversation where you describe what you want, Claude Code begins executing in your terminal, and you review and approve actions as it works. For longer tasks, you can let Claude Code run autonomously while you do other things, or stay in the loop for each significant step.
Devin's task ticket maps to your initial prompt in Claude Code, often supplemented by the CLAUDE.md file for standing project context. Good prompts for Claude Code include the goal, relevant constraints, how to test the result, and any specific approaches to prefer or avoid.
Devin's sandboxed environment maps to your actual repository checked out locally. This is a meaningful difference: Claude Code has access to your real files, can run your actual test suite, can read your .env file (with permission), and can interact with services running on localhost. There's no import step or environment setup required because the environment is already yours.
Devin's PR creation maps to Claude Code's ability to stage and commit changes in your repository, with you deciding when and how to push and open the PR. Claude Code can write git commit messages and run git commands, but you control the final git push.
Devin's check-in mechanism (where Devin messages you with questions during long tasks) maps to Claude Code's real-time interaction. Claude Code pauses and asks when it's uncertain rather than making assumptions autonomously. This is by design; the model assumes you want to make the call on ambiguous decisions.
Setting up CLAUDE.md
This is the most impactful step in the migration and deserves its own section. A well-written CLAUDE.md dramatically improves Claude Code's usefulness on your specific codebase.
Include in your CLAUDE.md:
Project overview: What the codebase does, tech stack, key architectural patterns.
Development workflow: How to install dependencies, start the dev server, run tests, run linting. Exact commands, not descriptions.
Code conventions: Naming patterns, file structure expectations, which patterns to prefer for common tasks (e.g., "use React Query for data fetching, not direct fetch calls").
Important files and directories: Where the main entrypoints are, which directories contain generated code that shouldn't be edited, which config files are important.
What to avoid: Files that shouldn't be touched, patterns that have caused problems before, third-party code that shouldn't be modified.
A reasonable CLAUDE.md is 50-200 lines. Longer is not necessarily better; focus on the information that Claude Code can't infer from reading the code itself.
The actual migration steps
Step 1: Assess your Devin usage patterns. Before migrating, look at the tasks you've been using Devin for. Categorize them: routine bug fixes, new feature implementation, refactoring, code review, test writing. Each category maps to a different Claude Code interaction pattern.
Step 2: Install Claude Code. Claude Code runs as a CLI tool. Install it via npm (npm install -g @anthropic-ai/claude-code), authenticate with your Anthropic API key, and run claude in a repository directory to start a session. The first session is a good time to explore the basics before working on real code.
Step 3: Write CLAUDE.md for your main repositories. For each repository you were using Devin on, create a CLAUDE.md. Start with the development commands (install, test, lint, start) and the key architectural patterns. Add more detail over time as you discover what Claude Code asks about repeatedly.
Step 4: Start with a task you know well. Pick a type of task you've done in Devin frequently and understand completely. Run it through Claude Code. This gives you a clear comparison point and lets you evaluate output quality on familiar ground before trusting it with less familiar tasks.
Step 5: Adjust your prompting style. Devin prompts are often written as tickets: "implement feature X according to spec Y." Claude Code responds well to the same format, but benefits from more explicit context about the current state: "the current implementation in auth/login.ts uses JWT; we want to add refresh token support following the pattern in auth/refresh.ts." The more context you give about where things live and what patterns to follow, the better the output.
Step 6: Establish a permission workflow. Claude Code will ask for permission before running commands, modifying files, or taking actions with side effects. In the early sessions, pay attention to what it asks for permission to do. Over time, you'll develop a sense for which types of actions you want to always approve manually and which you can allow automatically.
Gotchas you'll hit
You need to be present. Devin's async model lets you assign a task and come back hours later. Claude Code is more synchronous; it pauses for input at decision points. For very long tasks, this requires more active engagement than Devin does. There are ways to run Claude Code in a more headless mode, but the default interaction model assumes you're available.
Your local environment is exposed. Claude Code operates on your actual filesystem. It can read files, run commands, and modify code. This is what makes it more capable, but it also means you should run it in repositories where you're comfortable with it having file access. Use .claude/settings.json to define explicit permissions and restrictions.
Context window size affects long tasks. Very large refactors or multi-file changes can approach context window limits, especially in large codebases. Break large tasks into smaller, bounded pieces. Use CLAUDE.md to give Claude Code standing context so you don't need to re-explain the project each time.
Prompting quality directly affects output quality. This is true of Devin too, but it's more apparent in Claude Code because you're in the loop for each step. Vague prompts produce more back-and-forth. Specific prompts with clear success criteria and references to relevant existing code produce faster, more accurate results.
API costs are usage-based. Claude Code's token costs depend on the amount of code it reads, the length of conversations, and the number of tool calls. Very large repositories with many files read per session can accumulate significant token usage. Monitor your API usage in the first few weeks to understand the cost pattern for your workflows.
No sandboxing by default. Devin's sandbox means its mistakes are contained. Claude Code operates on your actual environment. Use version control as your safety net: commit before each significant operation, or use a separate branch for Claude Code's work.
When NOT to switch
Devin remains the better choice in specific situations.
If you need long-running, fully autonomous execution across multiple hours with no attention required, Devin's sandboxed async model is designed for that. Claude Code's interaction model assumes periodic availability.
If your team doesn't have API key access to Anthropic's API, or if your security policy doesn't allow running a CLI tool with repository access on developer machines, Devin's isolated sandbox sidesteps those concerns.
If the tasks are well-defined enough that you genuinely don't need to be in the loop, and the per-task cost of Devin is affordable for your volume, the autonomy difference may outweigh the cost savings.
The migration is most compelling for teams that want to be in the loop on AI-generated code changes, have high task volumes where per-task pricing adds up, or want the AI to work within their actual development environment rather than a sandboxed copy.
Write a solid CLAUDE.md, start with tasks you understand well, and the comparison between Devin's outputs and Claude Code's will be apparent within your first week.