🔥 Top Story
Claude Code found my app’s shared contract in two MCP calls. Then the records ran out.
This New Stack piece examines a recurring Claude Code pain point: every new session starts from zero, with no memory of the system it's working on. The author connected Claude Code to their own application via MCP (Model Context Protocol) and found that just two MCP calls were enough for the model to infer the app's shared contract — the common data structure or interface used across services. The title suggests a catch, though: the process eventually runs out of the records needed to continue. Taken together, that's both a demonstration of how much MCP can shortcut the cold-start problem and a reminder that the shortcut has a limit. Because thenewstack.io was unreachable from this environment (network policy), this summary relies only on the article's title and excerpt, not the full text — the exact mechanics of the MCP calls and the "ran out of records" limitation are not confirmed.
💡 Why it matters: If two MCP calls are really enough for an LLM to reconstruct a service's shared contract, that could meaningfully cut onboarding time for engineers working on unfamiliar systems — but teams should also watch for the data-exhaustion failure mode the headline points to.
🔗 Read more · The New Stack
DevOps & Infrastructure
Claude found 29,000 possible bugs in open source. Only 516 have been fixed.
The New Stack
According to this New Stack article, Anthropic recently launched an "OSS Scanner" as part of its broader Cyber Mission initiative, a tool that scans open-source projects for potential security vulnerabilities. The headline figure is striking: the scanner flagged roughly 29,000 possible bugs across the open-source ecosystem, but only 516 of them have actually been fixed so far. That gap between detection volume and real remediation appears to be the article's central point. A roughly 1.8% fix rate on flagged issues, if that's really what's being described, points to a bottleneck somewhere between automated detection and maintainers actually shipping patches. Because thenewstack.io could not be reached from this environment, this summary is limited to what the title and excerpt state — details on which projects were scanned or why the fix rate is so low are not confirmed.
💡 A security scanner that surfaces tens of thousands of findings but sees only a couple percent actually patched is a reminder that automated OSS vulnerability detection needs a triage and prioritization layer before ops and security teams can act on it.
How to turn AI production feedback into better agents
The New Stack
This New Stack piece opens with the line "Your agent is live. The service is healthy" — framing a scenario where an AI agent looks fine from a pure uptime standpoint. As the title indicates, the article's focus is on how to turn that kind of production feedback into a loop that actually makes agents better over time. The excerpt alone doesn't specify which feedback signals (user ratings, failure logs, retry rates, etc.) or which companies or tools are discussed. Even from just that opening line, the article seems to be setting up a gap between a service merely being up and an agent actually performing well. Since thenewstack.io was unreachable from this environment, this summary stays within what the title and excerpt state and does not include specific examples or figures from the full article.
💡 If a "healthy service" status can mask real agent quality problems, teams running agents in production need an observability layer specifically for production feedback, not just uptime monitoring, to know when and how to improve the agent.
This digest was collected from RSS feeds and summarized by AI (Claude). See the original links for full details.