You've spent a session getting Cursor or Claude Code to build exactly the right data layer. The table structure, the relationships, the API calls — all correct. Then you start a new session, ask for a new feature, and the agent starts improvising. It re-derives the schema from what it can infer, makes slightly different assumptions, and you spend the first twenty minutes of the session correcting a data model that was already working.
This isn't a bug. It's a predictable consequence of how AI coding tools handle context.
Why Sessions Start From Scratch
AI coding tools like Cursor, Claude Code, and Codex don't have persistent memory across sessions by default. Each new session starts with a clean context window. The agent knows:
- What's in the files it can read right now
- What you tell it in the current conversation
- Whatever is in your AGENTS.md or .cursor/rules files
What the agent doesn't know, unless you provide it:
- Decisions made in previous sessions that didn't end up in files
- The reasoning behind your data model choices
- Which field names, table names, and relationships you've settled on
When an agent can't find a reliable schema, it does what it's trained to do: it reads whatever context is available and derives something plausible. If your database schema isn't directly accessible, "plausible" means re-inventing it from inference — and inference drifts slightly each time.
The Symptom: Accumulated Inconsistency
The rebuild problem compounds over time. In session one, the agent calls the user identifier user_id. In session three, it uses userId in one file and id in another. In session five, a new feature creates a profiles table that partially duplicates your existing users table because the agent didn't know the users table had profile fields.
None of these individual mistakes are catastrophic. Together, they create a codebase where different parts of the app have slightly different mental models of the same data, and debugging requires figuring out which assumption each file was operating under.
Why the Data Layer is the Most Expensive Thing to Re-Derive
Not all context is equally expensive to re-create. UI patterns are cheap to re-derive — you can infer a lot from existing components. Business logic is moderate — it's usually encoded in code the agent can read. But the data layer is expensive, because:
- The ground truth isn't always in the code. Your database lives in a separate system. If the agent can't query it, it reads whatever migration files, comments, or API responses are available — incomplete pictures.
- Conventions matter and aren't visible. Your choice to use snake_case, to put created_at timestamps on every table, to enforce uniqueness on emails — these live in the schema and in your head, not in the application code.
- Relationships aren't always explicit. A foreign key in a migration file tells the agent about one relationship. A visual data model tells it about all of them, including the ones that don't have explicit code yet.
When the agent re-derives the data layer wrong, you don't just get wrong code — you get code that's internally consistent with the wrong model, which is harder to fix than obviously broken code.
The Fix: Make the Schema Authoritative and Machine-Readable
The schema-first workflow breaks the rebuild cycle at the root cause. Instead of the agent re-deriving the data model each session, it reads the authoritative, current schema directly. The fix has two parts:
Part 1: Define the data model once, in a place the agent can read it
This means your data model needs to exist somewhere machine-readable — not just in your head, in comments, or in a README. Options:
- A live database with introspection. A Postgres database with a connected MCP server lets the agent query the actual schema at the start of each session.
- A GraphQL API with introspection enabled. GraphQL's introspection query returns the full schema — every type, field, and relationship — in a format designed for machine consumption.
- A well-maintained schema file. TypeScript interfaces, Prisma schema, or a GraphQL SDL file committed to the repo. Less dynamic, but readable.
Part 2: Give the agent a rule to read it before acting
An AGENTS.md or .cursor/rules entry that says "before writing any database-related code, introspect the schema" turns your machine-readable schema into something the agent actively uses rather than skips.
Combined, these two changes mean the agent starts every session with an accurate model of your data layer — not one derived from guesswork.
How Momen Implements This Pattern
Momen is a visual backend that's designed around this exact principle. You define your data model once — tables, relations, field types, constraints — in Momen's visual editor. The editor exposes the entire model as a typed GraphQL API with introspection enabled.
When Claude Code or Cursor connects to Momen via the Plugin or MCP, the first thing the agent does is introspect the schema. Every field name, type, relationship, and available Actionflow is available before the first prompt in a new session. There's nothing to re-derive because the authoritative source is directly accessible.
When you add a new table or change a field type, the agent's next session automatically sees the update. You don't update documentation, you don't paste schema excerpts into chat — you change the model, and the agent reads the change.
See Beyond the Visual Editor for more on how Momen's API layer exposes the visual data model to external tools, and How I Built a Legal Intake and Triage App with Claude Code and Momen Backend for a concrete example of schema-first development across multiple sessions.
Momen's database configuration docs cover how to set up the data model that becomes the schema the agent reads.
The Workflow in Practice
A schema-first session looks like this:
- New session starts. The SessionStart hook (for Claude Code) or initial MCP connection (for Cursor) loads the current schema.
- Agent reads the authoritative data model. It knows all existing tables, field names, types, and relationships before you type anything.
- You ask for a new feature. The agent generates code that works with your actual data model — correct column names, correct types, correct relationships.
- You update the data model. You add a new table or field in Momen's visual editor. The schema changes immediately.
- Next session starts fresh — but informed. The agent reads the updated schema. It knows about the new table.
The rebuild cycle breaks because the agent is never guessing. It always has something accurate to read.
Summary
AI coding tools rebuild your app from scratch because they can't access your data model across sessions — so they re-derive it from inference, and inference drifts. The fix is schema-first development: define the data model once in a machine-readable, introspectable format, and give the agent a rule to read it before acting.
A visual backend like Momen makes this straightforward by design: define the model visually, let the GraphQL API expose it, connect to your AI coding tool, and the agent reads the real thing every session. The data layer stops being a source of inconsistency and starts being the stable foundation that makes every session more accurate than the last.
Top comments (0)