Why does Devin forget my coding style?

Devin forgets your coding style because each Devin session is an autonomous run that does not automatically inherit reasoning from previous sessions, and Knowledge entries are account-wide rather than project-specific. Style rules typed inside a session live and die with that session. The fix is to attach a per-project memory layer Devin reads at session start.

Devin is Cognition's autonomous engineering agent that plans, codes, and runs tests inside a managed sandbox. Three design choices push your style rules out of the next run:

1. Sessions reset the working context. Every Devin run spins up a fresh sandbox and a fresh conversation. Style directions you gave mid-session — "use named exports, not default; use cn(), not clsx" — are local to that session and do not load into the next one.

2. Knowledge entries are global guidance, not project rules. Devin's Knowledge feature persists facts across sessions, but they apply account-wide. Useful for "always run lint before commit". Less useful when two repos in the same account have different conventions.

3. The agent re-derives style from the repo. Devin reads files to infer conventions, which is reasonable when conventions are consistent. In repos under active migration — half-converted to a new pattern — Devin picks the wrong half and codifies it. The official Devin docs at docs.devin.ai describe the session and Knowledge model in detail.

The result: style holds for the duration of a session, and drifts the moment a new one starts.

The cost is not just aesthetic — it shows up in review and in shipping speed:

• Mixed conventions in one PR. Three new files use named exports, two use default. Two use Result<T, E>, one throws. Reviewers spend their time on style instead of logic.
• Re-litigated decisions. "We agreed to drop barrel files" is something Devin happily proposes again next session because the decision never persisted.
• Disagreement with human teammates. Your team agreed on a style. The agent drifts from it. PRs become a tug of war between human and agent diffs.

The fix is not "write a stricter brief each session" — it is to give Devin a project memory of style rules it loads automatically.

Cognition gives you three persistence tools. None pins style cleanly to a project.

Knowledge is the closest thing to persistent rules. It is global, manually maintained, and not scoped to a repo, so multi-project teams either bloat Knowledge with conditionals ("in repo X, do Y") or accept that style enforcement is per-session.

Repo setup scripts can install linters and formatters, which catch some style violations after the fact. They do not change how Devin writes code in the first place.

Linked PRs and prior sessions let you reference earlier work in a new brief. You still have to point Devin at the right session and trust it to extract the right style cues from prose.

The deeper issue is that coding style is a project asset. It should live with the project, version with the project, and travel with the project to any tool — Devin, Cursor, Claude Code, ChatGPT — your team uses.

Knowledge entries handle global preferences. Multi-project, multi-tool style enforcement needs a layer above the agent.

MemoryLake is a cross-model memory layer Devin reads from at session start over REST. Instead of duplicating style rules into global Knowledge, you store them as Memories pinned to the project and let every session retrieve only what is relevant.

• Style as project-scoped memory. "Named exports, Result types, TanStack Query" lives as structured Memories inside the project. Different repos get different rules without polluting global Knowledge.
• Same rules across humans and agents. The same style memory used by your developers in Cursor or Claude Code is what Devin pulls at session start. No drift between human and agent code.
• 10,000× the retrieval reach of raw prompting. MemoryLake's engine reads from billions of tokens of project memory and returns only the style rules relevant to the files Devin is editing.

MemoryLake scored 94.03% on the LoCoMo long-context benchmark, the top published result as of 2026, with millisecond retrieval and AES-256 end-to-end encryption.

1. Create a project and load your context. Sign in to MemoryLake, open Project Management, click Create Project, and name it "Devin — Acme web style". Upload your style guide, ESLint config, ADRs, and conventions docs through the Document Drive. Add explicit rules — "named exports only", "no default exports", "Result types for fallible code" — as Memories in the Memories tab.
2. Generate an MCP Server endpoint. Open the MCP Servers tab inside your project, click Add MCP Server, name it "Devin style memory", and click Generate. MemoryLake returns an API key ID, secret, and endpoint URL. Copy the Bearer token immediately — it is shown only once.
3. Connect Devin via REST. Add a setup or pre-session hook to your Devin workflow that calls MemoryLake's REST endpoint with the Bearer token, pulls the project's style memory, and writes it into the task brief or Knowledge before the run starts. Every session now opens with the project's style rules in front of the agent.