Devin AI vs Claude Code: How Each Handles Project Configuration and Rules Files (2026)

Devin AI and Claude Code sit at opposite ends of the autonomy spectrum among AI coding agents, and that difference shows up directly in how each one reads project configuration. Claude Code is a session-based terminal and IDE agent that a developer drives interactively, checkpoint by checkpoint. Devin AI is Cognition’s autonomous software engineering agent, historically built to take a task, work unsupervised in an isolated cloud sandbox, and return with a pull request. Cognition has since shipped Devin for Terminal (Devin CLI), a more interactive, Claude-Code-like surface — which means “Devin” today is not one product with one config story, but at least two.

This comparison stays narrow on purpose: not “which agent is better,” but specifically how each tool ingests project context, what file formats each supports, and how their different autonomy models change what a rules file is even for.

Quick Definitions

Claude Code is Anthropic’s terminal and IDE coding agent that reads a project’s CLAUDE.md file (and related .claude/rules/ files) at the start of every session to apply persistent, developer-written instructions to its work.

Devin AI is Cognition’s AI software engineering agent, offered as an autonomous cloud product (app.devin.ai) and as an interactive terminal tool (Devin CLI), both of which can be configured with persistent instructions but through meaningfully different mechanisms.

Claude Code and Devin Are Not Symmetrical Products

Before comparing config formats, it’s worth being precise about what’s actually being compared, because the two “Devins” don’t work the same way.

Claude Code is a single, consistent product: a CLI and VS Code extension that reads instruction files from your working directory tree at the start of every session and applies them as context for an interactive, developer-supervised loop.

Devin ships as (at minimum) two distinct interfaces with different configuration mechanisms:

1. Devin (cloud/web product, app.devin.ai) — the original autonomous agent. Project setup happens through a web UI: a “Repository Settings” flow that walks through git pull commands, secrets, dependency installation, lint and test commands, and a freeform “Additional Notes” field for instructions specific to that repo. Persistent cross-session guidance is handled by two separate systems — Knowledge and Playbooks — both described below. Official repo-setup documentation does not describe this cloud product automatically discovering and reading an AGENTS.md file from the repository the way Claude Code reads CLAUDE.md.
2. Devin for Terminal (Devin CLI) — a newer, interactive CLI agent. This surface natively reads AGENTS.md files from the project root and a global config directory, closer in spirit to how Claude Code, Cursor, and other CLI-based tools work.

This split matters for anyone trying to standardize rules across tools: “does Devin support AGENTS.md?” has a different answer depending on which Devin you mean.

How Claude Code Ingests Project Context

Claude Code’s mechanism is a single, well-documented file hierarchy.

CLAUDE.md is the native file — not AGENTS.md. Per Anthropic’s current documentation: “Claude Code reads CLAUDE.md, not AGENTS.md.” If a repository already maintains an AGENTS.md for other tools, the documented pattern is to create a CLAUDE.md that imports it with @AGENTS.md, optionally appending Claude-specific instructions below the import, or to symlink CLAUDE.md to AGENTS.md directly (symlinks require admin privileges or Developer Mode on Windows, so the import syntax is the cross-platform default).

File scope and load order, from broadest to most specific:

Claude Code walks up the directory tree from the working directory, loading every CLAUDE.md and CLAUDE.local.md it finds along the way, then concatenates them (not overrides) into context — files closer to the working directory are read last, so their instructions take precedence when rules conflict. CLAUDE.md files in subdirectories below the working directory load on demand, when Claude actually reads files in that subdirectory, rather than all at launch.

Imports use @path/to/file syntax, resolve relative to the file containing the import, and can recurse up to four hops. This is also the documented mechanism for pulling in AGENTS.md, a README, or a package.json without duplicating content.

.claude/rules/ lets larger projects split instructions into topic files (testing.md, security.md, etc.), optionally scoped to specific file paths via YAML frontmatter (paths: ["src/api/**/*.ts"]) so a rule only enters context when Claude is actually touching matching files.

Auto memory is a separate, complementary system: Claude writes its own notes to ~/.claude/projects/<project>/memory/MEMORY.md based on corrections and preferences it picks up during sessions — build commands, debugging insights, things you told it once that it decided were worth remembering. CLAUDE.md is what you write; auto memory is what Claude writes.

All of this — CLAUDE.md, imports, .claude/rules/, auto memory — is loaded automatically at the start of every session with no manual attachment step required.

How Devin Ingests Project Context

Devin’s story is split across three distinct mechanisms, and which ones apply depends on which Devin interface is running.

1. Devin CLI: AGENTS.md and .devin/config.json

Devin for Terminal reads project rules from, in order of preference: AGENTS.md (recommended), AGENTS.local.md (personal, gitignored rules), or AGENT.md (singular alternative) at the project root. Global rules that apply across every project live at ~/.config/devin/AGENTS.md on Linux/macOS or %APPDATA%\devin\AGENTS.md on Windows, and are loaded at the start of every session regardless of which project is open.

Devin CLI also supports a separate project-level config file, .devin/config.json, committed to version control, for team-shared settings that are structurally different from rules text: MCP server definitions, permission policies (allow/deny/ask rules), lifecycle hooks, and a read_config_from setting that imports rule formats from other tools directly — Cursor’s .cursor/rules/*.md, Windsurf’s .windsurf/rules/*.md, and Claude Code’s .claude/ directory files.

Precedence runs from organization-level settings (which cannot be overridden by project or user config) down through project config to user config — the inverse of Claude Code’s “most specific wins” model in the sense that Devin’s CLI explicitly walls off enterprise policy from local overrides, but agrees with Claude Code in putting project-level settings above personal ones.

2. Devin cloud product: Repository Settings, Knowledge, and Playbooks

The original, autonomous Devin has no equivalent single rules file that’s auto-discovered from the repo. Instead:

• Repository Settings is a web UI, configured once per repo, covering git pull commands, secrets, dependency install/maintenance, lint and test commands, how to run the app locally, and a freeform “Additional Notes” box for instructions.
• Knowledge is a database of tips, advice, and instructions, managed through the Devin web app rather than checked into a repository. Each Knowledge item has a trigger description — the phrases or context that should cause Devin to recall it — and is scoped to an organization (visible to all members) or, in enterprise accounts, promoted to apply across every organization. Devin retrieves Knowledge contextually when current work matches a trigger, and can also suggest new Knowledge items based on your in-chat feedback, which you approve, edit, or dismiss.
• Playbooks are reusable prompt templates for a specific recurring task — closer to a custom system prompt than a rules file. A playbook typically documents a procedure (setup step, task step, delivery step) and postcondition specifications. Playbooks are attached explicitly per session (by picking one from a library, or typing an assigned macro like !deploy-checklist) rather than being loaded automatically the way CLAUDE.md or AGENTS.md are.

None of Repository Settings, Knowledge, or Playbooks is a version-controlled markdown file living in the repo the way AGENTS.md or CLAUDE.md is. They live in Devin’s platform and are managed through its UI.

Two Concrete Configs

Claude Code — importing a shared AGENTS.md and adding tool-specific instructions:

# CLAUDE.md
@AGENTS.md

## Claude Code
Use plan mode for changes under `src/billing/`.
Run `npm run typecheck` after any edit to `src/api/`.

Devin CLI — a project AGENTS.md plus .devin/config.json for permissions and MCP:

# AGENTS.md
This is a Next.js 14 app using the App Router. TypeScript is required
everywhere. Run `npm run lint` and `npm test` before considering a
task complete. API routes live in `src/app/api/`; do not add routes
under `pages/`.

{
  "permissions": {
    "allow": ["npm test", "npm run lint"],
    "ask": ["git push"],
    "deny": ["rm -rf"]
  },
  "mcpServers": {
    "postgres": {
      "command": "npx",
      "args": ["@modelcontextprotocol/server-postgres", "postgresql://localhost/app"]
    }
  },
  "read_config_from": ["claude"]
}

Note the last line: Devin CLI can be told to also import Claude Code’s .claude/ rule files directly, which is one practical way to avoid maintaining parallel instruction sets if a team runs both tools.

Autonomy Model: Why the Same Problem Gets Different Answers

The structural difference between these config systems is not arbitrary — it follows from how much unsupervised time each agent actually spends running.

Claude Code operates in tight, developer-supervised loops. A session is interactive by default: the developer sees diffs, approves tool calls (unless permissions are pre-granted), and can redirect Claude mid-task. In this model, CLAUDE.md mainly needs to front-load facts the developer would otherwise re-explain every session — build commands, conventions, architecture — because the human is present to correct course in real time if the agent drifts. Hooks exist for the cases where you want hard enforcement instead of contextual guidance (“Claude treats CLAUDE.md as context, not enforced configuration,” per Anthropic’s documentation) — a PreToolUse hook, not a stronger sentence in the file, is the documented way to actually block an action.

The original Devin cloud product was built around long, unsupervised runs: assign a task, Devin works in an isolated sandbox, and a PR comes back later with no developer watching each step. That autonomy model raises the stakes on getting context right before the run starts, which is presumably why Devin split configuration into three purpose-built layers instead of one file: Repository Settings covers the mechanical facts a setup script needs (how to install, lint, test, run), Knowledge covers durable organizational judgment (“we don’t use moment.js, migrate to date-fns,” “always check the feature-flag service before touching this table”) that should apply to every future session without a developer re-attaching it, and Playbooks cover repeatable procedures for specific task types that a developer explicitly chooses to hand Devin, since not every session should run every procedure.

Devin CLI’s AGENTS.md support narrows that gap. As an interactive terminal tool, it behaves more like Claude Code — and its documentation leans on the same cross-tool file format that Codex CLI, Cursor, and Windsurf increasingly share, rather than Devin’s own bespoke UI-managed system.

Comparison Table

FAQ

Does Devin support AGENTS.md?

It depends which Devin. Devin for Terminal (Devin CLI) natively reads AGENTS.md at the project root and at ~/.config/devin/AGENTS.md globally. The original cloud-based Devin product configures repos through a web UI (Repository Settings) plus Knowledge and Playbooks; its official repo-setup documentation does not describe automatically discovering an AGENTS.md file from the repository.

Does Claude Code support AGENTS.md?

Not directly. Anthropic’s documentation states plainly: “Claude Code reads CLAUDE.md, not AGENTS.md.” The supported pattern for sharing instructions with other AGENTS.md-based tools is to create a CLAUDE.md that imports it (@AGENTS.md) or to symlink the two files together.

What is the difference between Devin’s Knowledge and Playbooks?

Knowledge is durable, contextually-triggered background information — coding standards, gotchas, internal tooling notes — retrieved automatically when Devin’s current work matches a trigger description. Playbooks are task-specific procedures you explicitly attach to a session, closer to a saved prompt template than persistent context.

Can Claude Code and Devin CLI share the same rules file?

Largely yes. Devin CLI reads AGENTS.md natively and can additionally import Claude Code’s .claude/ rule files via its read_config_from config setting. Claude Code, in the other direction, can import an AGENTS.md file into its CLAUDE.md. A team can maintain one AGENTS.md as the source of truth and layer tool-specific additions on top in each tool’s native format.

Why doesn’t the original Devin product just read AGENTS.md like the CLI does?

Cognition hasn’t published a stated reason, so this is inference from the documented product design rather than an official claim: the cloud product runs unsupervised for long stretches, and its config system (Repository Settings + Knowledge + Playbooks) separates mechanical setup, durable judgment, and repeatable procedures into three UI-managed layers rather than one text file. Whether that’s a deliberate design choice or a gap likely to close as Devin CLI’s file-based approach matures isn’t something the documentation states.

Does Claude Code have anything like Devin’s auto-suggested Knowledge?

Somewhat. Claude Code’s auto memory writes its own notes to MEMORY.md based on corrections and preferences observed during sessions, without a manual approval step for each note (though everything it writes is plain markdown you can review and edit via /memory). Devin’s Knowledge suggestions, by contrast, require you to review and explicitly save or dismiss each suggested item before it becomes part of Devin’s permanent context.

Is a .devin/config.json the same thing as AGENTS.md?

No. AGENTS.md (and its variants) carries natural-language instructions Devin CLI applies as context. .devin/config.json carries structural configuration — MCP server definitions, permission allow/deny/ask rules, lifecycle hooks, and settings for importing other tools’ rule formats. The two files are complementary, not interchangeable, similar to how Claude Code separates CLAUDE.md (instructions) from .claude/settings.json (enforced configuration).

Autonomous Agents Still Need Human QA

Both of these tools can be configured to work with less supervision than a developer typing every line — Claude Code through hooks and pre-approved permissions, Devin through Playbooks and long unsupervised sandbox runs. Neither eliminates the need for a human to actually look at what got shipped. A well-written AGENTS.md or CLAUDE.md reduces the odds of an agent doing the wrong thing, but it does not review a rendered UI, catch a broken layout on mobile, or notice that a form now submits twice.

That’s the gap a QA pass fills before a PR from Devin or Claude Code gets merged. BugHerd turns visual bugs into pinned, contextual tickets directly on the page — a fast way to have a human (or a teammate) sanity-check an autonomous agent’s output against the actual rendered app before it ships, rather than relying on the config file alone to have caught everything.