One of the fundamental challenges facing AI coding agents is context loss. LLMs lose memory across sessions — design decisions agreed upon yesterday, library selection rationale, architectural constraints all reset to zero. While manageable in small projects, the cost of this loss accelerates as codebases grow.
Several approaches are currently practiced to address this challenge. Each has clear strengths, but a common structural bottleneck is also becoming visible. This article surveys existing approaches and explains the architecture sqlew adopts.
Surveying Existing Approaches
Spec-Driven Development
This approach, represented by tools like AWS Kiro and GitHub Spec Kit, creates formal specifications upfront and communicates "What to build" clearly to the AI before code generation begins.
It works well for those experienced with structured development processes, and its strength lies in the organized flow from requirements to implementation. However, the specifications themselves incur management overhead. As projects progress, contradictions and duplication emerge across specs, and AI can become confused when old and new specifications conflict. The question of what granularity to split specs at also becomes a design burden for teams.
Rule Recording in CLAUDE.md and AGENTS.md
The most widely practiced approach. Place a context file in your project root, record coding conventions and architectural guidelines, and have the AI read it at the start of every session to carry context forward.
The barrier to entry is low, and it's highly effective in the short term. However, documentation tends to bloat as projects progress. When it bloats, AI sometimes omits portions of the rules, and research has shown that increased context length degrades LLM reasoning quality. "Context contamination" — where the right information exists in context but isn't effectively utilized — is a common outcome.
Documentation and Reuse via Skills
This approach documents specific procedures and patterns in Markdown, reusing them through mechanisms like Claude Code's Skills. It has strong affinity with AI automation and is effective for work that can be systematized into patterns.
However, the problem of documentation drifting from reality as projects evolve is unavoidable. Regular maintenance of outdated documentation is required, and this management cost shares the same structural challenge as spec-driven development.
The Common Bottleneck
Each of these approaches is valid, and they should be selected based on project scale and context. But the common pattern that emerges is this: human management work ultimately becomes the bottleneck. Writing documentation, updating it, maintaining consistency, pruning obsolete content — this management work grows heavier as projects scale.
As discussed in our previous article, Vasilopoulos (2026) found that 108,000 lines of code required approximately 26,000 lines of documentation, incurring 1–2 hours per week of maintenance. The more successfully you achieve context persistence, the more its maintenance becomes "second-order complexity" that constrains development. This is the current dilemma.
sqlew's Approach
sqlew addresses this dilemma with an architecture that delegates both recording and retrieval to the AI itself.
Automatically Recording "Why" Alongside "What"
At sqlew's core is automatic ADR (Architecture Decision Record) recording linked to the AI agent's Plan Mode.
AI coding tools like Claude Code and Codex include a Plan Mode where the AI formulates an implementation plan before coding. sqlew hooks into this Plan Mode: every time the AI creates a plan and a human approves it, the design policy (What) and the rationale behind it (Why) are automatically recorded in a SQL database.
Developers don't need any special operations. Just develop normally using Plan Mode, and design decisions with their rationale accumulate in the background.
Just-in-Time Suggestion of Only Relevant Context
Recorded information is automatically suggested during subsequent plan creation. This is the keystone of sqlew's architecture.
When the AI creates a plan for a new task, sqlew searches past records for similar content and injects only relevant policies and constraints into the context. Past records unrelated to the current task are not loaded.
This simultaneously solves two problems:
- Preventing context contamination: Information irrelevant to the current task doesn't enter the context window, preserving reasoning quality
- Avoiding context window pressure: Instead of dumping everything, only the needed portion is retrieved, using window capacity efficiently
In contrast to CLAUDE.md's "load everything every time" approach, sqlew performs selective retrieval — delivering only what's needed, when it's needed.
The Database Grows into an AI Knowledge Base
sqlew's effectiveness accelerates as the knowledge base accumulates.
Early in a project, records are sparse and suggestions limited. But as turns accumulate, design decisions build up in the database, enriching the context available to the AI. In our controlled experiment, we observed a positive feedback loop where prior decision reference frequency accelerated through the later stages of a project (+21% → +64% → +137%).
AI thinking quality shifts, and suggestion effectiveness compounds. Concretely, at advanced project stages the AI begins making proposals like these:
"I found a record showing this design was chosen for a specific reason. Implementing your current instruction would require significant refactoring. We could also bypass the existing design and implement directly at the cost of consistency — which approach would you prefer?"
"This may conflict with a feature that's recorded as planned for future implementation. Which has higher priority?"
These proposals are possible only because the AI "knows" past design intent. Rather than a passive tool waiting for instructions, it functions as a partner that can anticipate issues based on project context. The larger the project and the more turns it accumulates, the more pronounced this effect becomes.
Context Persistence Without Human Cost
The fundamental difference between sqlew's architecture and existing approaches is that both recording and retrieval are handled by the AI.
Traditional ADRs were written by humans and referenced by humans. This dual burden — where the writer and reader are the same person — was the root cause of ADR adoption failure. In sqlew, both the writer and reader are AI (LLM agents), with the human role limited to plan approval only.
Since there's no need to manually maintain documentation, the "second-order complexity" of documentation management doesn't arise. Achieving the same or greater effectiveness as document-based context persistence — without human management cost. That's what sqlew's architecture aims for.
Honest Limitations
sqlew is not a silver bullet. We want to be upfront about its constraints.
Limited Effectiveness for Mid-Project Adoption
sqlew is most effective when design rationale can be recorded from the very beginning of a project. While AI can extract specifications from existing codebases, retroactively inferring "Why that specification exists" is inherently difficult.
Effective Retroactive Adoption
That said, adoption for existing projects isn't impossible. Having AI infer design rationale from meeting notes on spec design, GitHub Issues, and PR discussions is a practical path. In our experiment, the condition where ADR was introduced mid-project showed slightly lower evidence quality but achieved comparable policy reference frequency to from-inception adoption.
Initial Overhead
When the knowledge base is still sparse in the early adoption phase, sqlew checks for suggestions with each plan creation, but often returns zero results because no relevant past records exist yet. This suggestion checking itself consumes several hundred tokens per occurrence, creating a period where overhead feels larger than the benefit.
In our experiment as well, the sqlew condition appeared slightly disadvantaged in the first few turns. But as the project grew complex, the accumulated design decisions' effect far outstripped the overhead.
Summary
Existing approaches to context loss each have their strengths: spec-driven development's structured clarity, CLAUDE.md's accessibility, Skills' reusability. sqlew doesn't replace these — it coexists with CLAUDE.md, complementing it with dynamically accumulated design context.
Recording not just "what to build" but "why to build it that way" — accumulated without human intervention, delivered just-in-time and just enough. sqlew continues development as a practical option for context persistence in AI-assisted coding.
References
- Kitayama, S. (2026). "Rediscovering Architectural Decision Records: How Persistent Design Context Improves LLM Code Generation" — https://doi.org/10.36227/techrxiv.177205025.54351571/v1
- Vasilopoulos, A. (2026). "Codified Context: Infrastructure for AI Agents in a Complex Codebase" — arXiv:2602.20478 — https://doi.org/10.48550/arXiv.2602.20478
- Chroma Research. "Context Rot: How Increasing Input Tokens Impacts LLM Performance" — https://research.trychroma.com/context-rot
- Liu, N. F. et al. (2024). "Lost in the Middle: How Language Models Use Long Contexts" — https://doi.org/10.1162/tacl_a_00638
- Anthropic. (2025). "Effective Context Engineering for AI Agents" — https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
