Claude Code found my app’s shared contract in two MCP calls. Then the records ran out.
The New Stack Ignacio Aldama
Claude Code found a shared app contract from Bit’s component records in two MCP calls. It worked until behavior and test coverage ran out.
Based on reporting by The New Stack, Ignacio Aldama — read the original for the full story.
Summary, retelling and take written by AI under human oversight; images are AI-generated illustrations. How we work · Report an error
Claude Code usually starts a fresh session by relearning the basics of a codebase. That can mean rediscovering which service owns the data, which frontend talks to it, and which type they both share. The article tests a different source of context: dependency records written when components are versioned, not a chat summary or a memory note.
The test project was a small support console built in bit-oss.support, with four components: a React app, an Express service backed by MongoDB, a shared ticket entity, and a platform component that puts the app and service behind one gateway. In a clean Claude Code session with no history and no local code, the prompt asked for filtering by ticket status and assignee. Claude first checked the workspace, saw it was empty, and then used MCP to read the remote scope.
From there, the agent called `read_scope` for bit-oss.support, then `read_components` for the app, service, and ticket entity. That gave it API references and file inventories before it imported source or touched code. The key detail was the shared ticket entity: both the app and the service depended on the same version, and its documentation said it was shared between the support service and the agent-facing app. Claude then imported all four components with `bit import`, inspected the code, and added the filtering logic in the app itself.
The result was clean enough: 41 passing tests, including nine new filtering tests. The change stayed in the app, which was exactly the point. Knowing what is shared helps an agent avoid poking the wrong thing.
But the records only go so far. The app’s API docs list the routes used in tests, including `GET /tickets`, `POST /tickets`, `PATCH /tickets/:id` and `POST /tickets/:id/comments`, but nothing checks those against the real service. The MongoDB integration tests can also skip if the temporary database will not start on the CI runner, so a green build does not prove they ran.
That leaves the messy part of engineering where hand checks still matter: persistence, recovery, migrations, and concurrency control. The build records were enough to recover the shared contract in two MCP calls, but behavior still had to be verified the old-fashioned way. Memory can tell an agent what people meant. Dependency records can tell it what the system is. Neither gets to skip the rest of the job.
My take — AI-written commentary, not fact-checked reporting
This is the sane version of agent tooling: record structure when it’s created, then stop pretending memory can replace it. A lot of AI plumbing is really just organized forgetfulness with a nicer dashboard. The dull stuff — shared contracts, versions, dependencies — is where the real leverage lives, which is deeply unglamorous and therefore probably correct.
Read more about this at: The New Stack