Devin's Memory and 'Dreaming': How AI Coding Assistants Learn from Collaboration

AI coding assistants are evolving from 'one-off conversation tools' to 'persistent collaboration partners.' Cognition's Devin recently revealed how its memory system works, built around two core mechanisms: Memory, which lets Devin retain useful knowledge about your working habits across sessions, and Dreaming, a daily asynchronous process that optimizes Devin's memory index about you.

Memory: Accumulating Working Habits Across Sessions

A major pain point of traditional AI coding tools is 'amnesia'—every time you start a new conversation, the assistant knows nothing about your code style, project structure, or preferences, forcing users to repeatedly explain context. Devin's Memory mechanism aims to solve this: it retains useful experience accumulated during collaboration with the user and recalls it in subsequent sessions.

The key phrase here is 'about you'—not generalized programming knowledge, but your personal preferences. For example, your preferred commit message format, your favored testing framework, your tendencies when choosing between certain code patterns. Individually these details seem trivial, but cumulatively they determine whether an assistant is 'a new hire who needs retraining every time' or 'a partner you've already built rapport with.'

From a product design perspective, Memory's value lies in reducing the marginal cost of collaboration. The initial setup investment gets amortized across every subsequent interaction.

Dreaming: The Asynchronous Index Layer for Organizing Memories

Dreaming is the more counterintuitive part of this system. It's not about letting Devin 'contemplate life' during idle time, but rather a daily asynchronous process specifically designed to improve Devin's index of user memories.

This design choice is worth noting: Dreaming optimizes not the memory content itself, but the index structure used to retrieve those memories. As an analogy, Memory is placing books on a shelf, while Dreaming is reorganizing the library catalog every day so the next search is faster and more accurate. As memory entries grow, retrieval quality degrades without continuous index optimization—Dreaming targets exactly this scaling problem.

'Daily asynchronous' means it doesn't consume real-time compute during interactions, so users don't perceive any waiting. This is an engineering-sound choice: memory organization is a latency-insensitive task that can easily be pushed to background batch processing.

Vector retrieval and indexing is the key background for understanding Dreaming. Modern AI memory systems generally use vector databases to store memory entries, encoding each memory as a high-dimensional vector; retrieval works by computing the similarity between a query vector and memory vectors to recall matches. The bottleneck of this approach: as entry counts grow, simple brute-force retrieval becomes increasingly slow, while approximate nearest neighbor (ANN) index structures (such as HNSW, IVF) need rebuilding or tuning after data distribution shifts, or recall rates drop. Dreaming's daily index reorganization essentially adapts the index structure to the currently accumulated memory distribution—a latency-insensitive offline maintenance task, decoupled from online inference, which is standard engineering practice.

What This Means for AI Coding Tools

Devin's approach points to a broader trend: the competitiveness of AI assistants is shifting from 'single-response quality' to 'long-term collaboration experience.'

Model capability is the foundation, but the memory system is the differentiation layer. Two coding assistants using the same underlying model—one remembers your project conventions, the other starts from scratch every time—will see their user experience gap widen continuously with usage duration. This also explains why Memory and Dreaming are presented in the same technical note—they're complementary: without Memory, index optimization is moot; without index optimization, more memories just mean more chaos.

For developers, a practical concern worth noting is memory controllability. Retaining 'knowledge about you' across sessions is convenient, but it also means clarifying: what information gets remembered, whether it can be viewed and deleted, and how to correct memories when they go wrong. The original notes didn't elaborate on these details, but this is a product question no persistent memory system can avoid.

The concept of AI memory layering involved here deserves elaboration. The industry typically divides memory into three types: short-term (current session context), long-term (cross-session persistence), and working memory (temporary state relevant to the current task). Devin's Memory belongs to the semantic layer of long-term memory, while Dreaming is closer to metadata management of long-term memory. Similar approaches appear in systems like MemGPT and Letta, with the core challenge being: how to let the model recall the most relevant handful of memories on demand without inflating the context window. This also explains why index quality directly determines experience—recall the wrong things, and no amount of memory helps; it's just noise.

Summary

Devin's memory architecture consists of two layers: Memory, responsible for accumulating cross-session working habit knowledge, and Dreaming, a daily asynchronous process that optimizes the memory index. The former solves 'remembering you,' the latter solves 'remembering at scale.' This combination pushes AI coding assistants from stateless tools to stateful collaboration partners, and also puts new issues like memory management and privacy control on the table.