DEV Community: Dennis Pilarinos

One Instructions File to Rule Your Agent: What AGENTS.md and CLAUDE.md Can and Can't Fix

Dennis Pilarinos — Mon, 24 Aug 2026 15:30:00 +0000

Fabien Sanglard's "My agent.md to improve LLM-assisted code quality" spent the weekend parked on the Hacker News front page: 325 points, 138 comments, and a thread full of engineers trading rule files like recipes. One tab over, GitHub's trending chart belongs to andrej-karpathy-skills, a repo built around a single CLAUDE.md distilling Andrej Karpathy's public observations about LLM coding pitfalls; it's sitting at roughly 206,000 stars, and Karpathy didn't even write it (more on that below). If you wanted proof that the single-file agent instructions pattern owns the current discourse, this was the week.

In brief: A markdown file at your repo root is the cheapest, most portable way to teach a coding agent your conventions, and this week's 325-point thread and 206k-star repo show how much demand there is for exactly that. But the pattern has a structural ceiling: files rot as conventions change, contradictions get resolved arbitrarily, and static text can't describe a moving system. Keep the file for stable rules. Retrieve everything else at runtime.

Why is everyone shipping a single instructions file?

Because every vendor finally agreed to read one. AGENTS.md, the open format now stewarded by the Linux Foundation's Agentic AI Foundation, is consumed by OpenAI Codex, Cursor, GitHub Copilot, Google Jules, Zed, Aider, and a long tail of others, with over 60,000 open-source projects already carrying the file. Copilot picks it up anywhere in your repo, plus CLAUDE.md or GEMINI.md at the root. Claude Code reads CLAUDE.md and documents a one-line @AGENTS.md import so both tools share a source. We've mapped the format differences in CLAUDE.md vs AGENTS.md vs Cursor rules.

The demand side is just as loud. Sanglard describes the itch precisely: he kept typing the same corrections into every session ("don't use magic numbers," "keep function names short") until he wrote them down once. And the star velocity on the Karpathy-derived repo, which packages four behavioral principles a community developer extracted from Karpathy's January post on X (Karpathy has no affiliation with the repo), says a few hundred thousand people share that itch. The repo's four principles (think before coding, simplicity first, surgical changes, goal-driven execution) fit in 65 lines, which is arguably the whole point: the pattern's pitch is that 65 well-chosen lines beat any amount of scaffolding.

What does the pattern actually get right?

More than the skeptics admit. A single agent instructions file is portable across tools, versioned with your code, reviewable in a pull request, and needs zero infrastructure. That last property is quietly radical: your agent's operating guidance gets the same diff-and-review treatment as the code it governs, instead of living in chat history and tribal memory.

There's evidence it helps, though it's thinner than the star counts suggest. A February 2026 arXiv study across four agent-model pairings found that developer-written context files nudged task success up by about 2.4% on average, a lift that fell short of statistical significance, and it confirmed that agents follow the instructions inside them closely. The authors' own conclusion lands where the practitioners have: these files earn their keep by specifying non-standard practices, not by boosting raw performance. And notice what Sanglard's rules and the Karpathy principles have in common: they're stable preferences. "Always use braces," "extract magic numbers," "make surgical changes" will be just as true next quarter. That's the sweet spot. Sanglard's own arc is instructive here: his mid-2025 attempts at LLM-assisted work produced code that didn't compile, while by 2026 the models could implement an indexed binary heap and pinpoint an obscure bug, yet still emitted what he calls spaghetti until the rules file reined in the style. His verdict is appropriately unsentimental: "LLMs constantly hallucinate and cannot be trusted." The file doesn't fix that. It just makes the review cheaper by making the output predictable.

The craft guidance is converging too. Claude's docs recommend staying under 200 lines, Copilot's docs advise keeping instructions under two pages, Codex caps combined size at 32 KiB by default, and Cursor suggests keeping rules under 500 lines. Short files get followed; sprawling ones get skimmed. If yours has sprawled, here's how to audit and fix a bloated CLAUDE.md.

Where does one file hit its ceiling?

The same place every static artifact does: the moment reality moves. Your team migrates test frameworks, renames a service, or reverses an architectural decision, and the file keeps confidently asserting the old world. Nobody gets paged when it drifts. We've traced that failure mode in rules file rot and in keeping agent instructions up to date.

Contradictions are worse, because they fail silently. Claude's own memory documentation is blunt: "if two rules contradict each other, Claude may pick one arbitrarily." Copilot's docs likewise warn against "conflicting sets of instructions." There's no compiler for your rules, no error, no lint. You find out when the agent does the wrong thing convincingly.

Then there's scale. One file per repo, times fifty repos, times three formats, is a synchronization problem masquerading as a documentation pattern; we've covered keeping CLAUDE.md, AGENTS.md, and .cursorrules in sync. The same arXiv study found LLM-generated instruction files made agents slightly worse in most of its test settings, and every kind of context file inflated inference cost by over 20% on average. Commenters on Sanglard's thread pushed further: plenty of these files are fossilized workarounds for model behaviors that no longer exist. Two more threads of skepticism from the discussion are worth stealing. First, anything a linter can enforce should live in the linter, where compliance is deterministic instead of probabilistic; the file should hold what tooling can't check. Second, frontier models need far less procedural coaching than their 2024 ancestors did, so a rule that made sense two model generations ago may now be pure context tax. Both arguments point the same direction: the file's honest scope keeps shrinking toward judgment calls only your team can make.

What belongs in the file, and what gets retrieved at runtime?

Split by rate of change. Stable and repo-scoped earns a line in the file:

Build, test, and lint commands, and the order to run them
Naming conventions, layering rules, and style calls your tooling can't enforce
The always/never list: approval workflows, forbidden directories, deployment rules
Pointers to deeper docs the agent should read before touching sensitive areas

Everything that changes weekly stays out. What shipped yesterday, what's in flight on a neighboring branch, what the ticket actually asks for, what that Slack thread decided at 4pm: none of it can live in a static file, because the file was true when it was committed and the work is happening now. This is the part of the pattern nobody's markdown template solves, and it's why teams that stop at the file keep watching their agent make confident, well-formatted mistakes.

That second half is what a context engine is for. Unblocked connects your repos, issue trackers, Slack, and docs so the agent queries current institutional context instead of trusting a snapshot; rules files vs a context engine walks through the architecture, and why not just Claude Code covers where the built-in memory stops. It's the difference between handing your agent a laminated card and giving it someone to ask.

Here's what that looks like in practice, from an engineer at Clio:

"I built a step called 'enrich' that runs before any code gets written. The agent asks Unblocked for everything — the ticket, the Slack context, what's been done in related repos — and then it starts implementing. It's especially powerful for cross-repository work where you'd otherwise have to do all that archaeology yourself."

— Arthur Rodolfo, Software Engineer, Clio

The file tells the agent how your team writes code. Retrieval tells it what's actually going on, which is the job of institutional memory and a shared team memory hub, not a markdown snapshot.

Frequently asked questions

Should I write AGENTS.md or CLAUDE.md?

Write AGENTS.md and bridge from there. It's the vendor-neutral format with the widest support, and tools that prefer their own filename can consume it: Claude Code documents a one-line @AGENTS.md import (or a plain symlink), and Copilot reads the shared file natively. Maintaining parallel hand-edited copies is exactly how instruction files drift apart, so pick one canonical file and generate or import the rest. Monorepos get nesting for free: Codex walks from the git root down and lets closer files override earlier guidance, and Cursor combines nested files with the more specific instructions taking precedence, so per-service rules can live next to the service.

How long should an agent instructions file be?

Shorter than the one you have. The vendors are unusually aligned here: under 200 lines (Claude), two pages (Copilot), 32 KiB combined (Codex), under 500 lines (Cursor). Adherence drops as length grows, because instructions compete with your actual task for attention. A useful habit: every time you add a rule, delete or verify one. Treat the file like an API surface, not an append-only log.

Do these files measurably improve agent output?

Barely, and only when humans write them. The arXiv evaluation found a 2.4% average lift from developer-written files that didn't reach statistical significance, a small negative effect from LLM-generated ones, and wide variance by model; Claude Sonnet 4.5 actually scored slightly worse with them while a smaller open model gained nearly eight points. The study's headline is blunter: context files don't generally improve success rates, and they add over 20% to inference cost. Benchmarks don't capture everything (consistency, review burden, avoided rework), but the data supports writing a small, deliberate file rather than generating a big one.

The file you should still write

Write the file. Keep it under a couple hundred lines, limit it to rules that were true last quarter and will be true next quarter, version it, and prune it on a schedule. Treat contradictions as bugs, because your agent will resolve them by coin flip, and treat every rule a linter could enforce as a rule that belongs in the linter. The pattern earned its moment on the front page honestly: cheap, portable, reviewable guidance beats re-typing corrections into a chat box forever, and the research agrees with the narrow version of the pitch, a file that encodes your non-standard practices, even if it won't move a benchmark.

Just don't ask a markdown file to be your team's memory. It's the stable layer of a two-layer system, and the dynamic layer, the tickets and threads and cross-repo history your agent needs mid-task, belongs to retrieval from a single source of truth that updates when your team does. One file to rule your agent's style. A context engine for everything the file can't know.

What 194 Engineering Teams Told Us About Their Homegrown Context Stacks

Dennis Pilarinos — Fri, 21 Aug 2026 09:30:00 +0000

Just over 4 in 10 of the engineering organizations we spoke with this year had already built, or were actively building, their own homegrown context stack: an internal system for feeding organizational knowledge to AI agents. Count the lighter improvisations too, the rules-file fleets and per-team MCP patchworks, and roughly 6 in 10 had rolled some form of their own. Almost none of them planned it as a product. It started as a hack that worked, and they were talking to us because it had stopped working.

That is the headline from 194 conversations we held with engineering teams evaluating context tooling between May and August 2026. This post is the aggregate: what the stacks look like, the lifecycle they follow, the five failure modes that recur with measurable regularity, and what teams said they wanted instead. Full methodology, including the selection bias you should apply to every number, is at the bottom.

Key Takeaways

Just over 4 in 10 of the roughly 150 organizations behind our 194 conversations had built or were building a substantive internal context system; about 6 in 10 had built something DIY, however small.
The dominant shapes: internal RAG over a wiki, vector databases over docs, Slack answer bots, custom centralized MCP servers, CLAUDE.md fleets, and per-team MCP patchworks.
The lifecycle is consistent enough to predict: build, early success, a staleness and maintenance wall, then an evaluation of alternatives. Roughly three in four builders described this arc.
Five failure modes recur: staleness with no owner (more than 4 in 10), token waste (roughly 4 in 10), no conflict resolution between sources (about a third), MCP and tool sprawl (about a third), and dedicated maintenance cost (about 3 in 10).
What teams asked for instead: permission inheritance, automatic freshness, one integration point, source authority that decides which truth wins, and measurable proof it works.

How many teams actually build their own context stack?

We counted an organization as a builder only if it had constructed something substantive: an internal retrieval system, a knowledge graph, a centralized context service, an answer bot with its own ingestion pipeline. By that stricter bar, just over 4 in 10 organizations qualified. These were not weekend experiments; several had dedicated squads assigned to the problem, and one large enterprise had recently rolled out an in-house context solution company-wide and was surveying the vendor market anyway.

Widen the definition to any deliberate DIY context mechanism, rules files replicated across repositories, individually maintained MCP configurations, a bot that answers questions in chat, and the share climbs to roughly 6 in 10. The instinct to build is close to universal; what varies is how far teams get before the economics assert themselves.

Two findings surprised us. Building was not correlated with company size: solo founders and organizations with tens of thousands of engineers both built, though large enterprises often had several parallel homegrown efforts that did not know about each other. And explicit refusal to build was rare but articulate; the teams that declined said, in effect, we do not want to build and manage this ourselves. Most teams learn that the slower way. The wider backdrop makes the volume unsurprising: in Deloitte's mid-2026 survey of 501 senior leaders, 42% of organizations had tested or deployed AI agents while only 15% had scaled an orchestrated agentic rollout, and a homegrown context stack is very often the artifact of a team trying to cross that gap alone.

What do homegrown context stacks look like?

The taxonomy was remarkably stable across industries, from fintech to healthcare to gaming. Five shapes cover nearly everything we heard.

RAG over the wiki

The most common substantive build: chunk the internal docs, embed them into a vector database, retrieve per query. It is the textbook architecture, and it inherits the textbook failure modes of temporal drift and entity confusion across chunks, plus a failure the textbook rarely names: no notion of authority. A handful of teams had layered knowledge graphs on top, usually after discovering that similarity search cannot distinguish current truth from well-written history.

Slack answer bots

A bot that fields "how does X work" questions in chat, backed by whatever retrieval the builder had time for. Teams liked the interface and disliked the answers; one described its internal bot as wrong most of the time, which is worse than no bot, because confident wrong answers spread further than silence.

Per-team MCP patchworks

About 3 in 10 organizations described every developer or team wiring up its own set of MCP servers: one for the issue tracker, one for the wiki, one for chat, each with its own API keys and reauthentication quirks. This is the configuration we have measured burning context windows before a task even starts, and the fatigue was audible: every laptop carrying its own pile of API keys and server configurations.

CLAUDE.md fleets

Roughly a third of organizations relied on rules files, CLAUDE.md, AGENTS.md, cursor rules, as their primary context mechanism, duplicated across repositories. The approach is legitimate at small scale, and the official guidance is candid about its limits: files past a couple hundred lines reduce adherence, and when two rules conflict the agent may pick one arbitrarily. At fleet scale it becomes a distribution problem: teams with repository counts in the hundreds described keeping those files consistent across all of them as a standing engineering chore of its own.

Curated internal knowledge bases

The static version: a hand-assembled corpus of best practices, architecture notes, and specs, maintained by one motivated person. These earned real early praise, and one consistent epitaph: static means obsolete unless somebody keeps feeding it, and somebody eventually stops.

What is the lifecycle? It worked, until it didn't

If the shapes vary, the arc does not. Roughly three in four builders narrated the same four-act story, unprompted. Act one: build. An AI-curious staff engineer or platform team assembles the stack in weeks, usually alongside their actual job. Act two: early success. The demo lands, leadership notices, adjacent teams ask for access. Act three: the wall. The index quietly goes stale, the maintainer gets pulled onto roadmap work, answer quality degrades in ways nobody measures, and trust erodes faster than the system does. Act four: the build vs buy context evaluation, which is where we met them.

A typical version of this sounds like (illustrative composite, not a real individual): "One of our senior engineers built RAG over the wiki last winter. The first month was genuinely impressive. Now the embeddings are three reorgs old, he maintains it between feature work, and the team quietly went back to asking each other questions in chat."

Two structural forces drive the arc. First, maintenance, not construction, is the cost center; industry analyses consistently put maintenance at more than half of a system's lifecycle cost, often several times the original build. Second, a context stack decays on a different clock than most internal tools. A stale dashboard is annoying; a stale context stack injects outdated facts into every agent that queries it, which is how agents end up recommending deprecated APIs with total confidence. The recurring realization: keeping the thing truthful is a full-time job nobody was hired to do.

What are the five failure modes?

Every frequency below is the share of the roughly 150 organizations in which the theme surfaced organically. Nobody was handed a questionnaire; these are rounded counts of what teams volunteered.

1. Staleness with no owner (more than 4 in 10)

The most common failure, and the most predictable. Docs written before the code changed, wiki sections describing systems that no longer exist, indexes on a refresh loop too slow for engineering questions. The sharpest formulation we heard, repeatedly and in different words: documentation stops being true the moment it is published, and the code becomes the only current source. The RAG literature keeps finding the same thing: semantic similarity has no correlation with recency, so a retriever cannot tell yesterday's truth from last year's. A 2026 twist: several teams worried that AI-generated documentation is inflating the corpus faster than anyone can curate it, garbage becoming a source for somebody else's agent.

2. Token waste (roughly 4 in 10)

Homegrown stacks tend to over-retrieve, because retrieval is cheap to build and relevance ranking is not. Teams described agents re-deriving the same architectural context every session, enterprise search dumping tens of thousands of tokens the model immediately discards, and MCP tool definitions consuming context before the first user message. This is the mechanical waste we've broken down in why AI agents burn tokens, and it compounds with scale: one leader at a 1,000-plus developer organization did the multiplication mid-call and did not like the product.

3. No conflict resolution between sources (about a third)

Covered in depth below, because it deserves it.

4. MCP and tool sprawl (about a third)

Every source got its own server, every server its own keys, and nobody owns the aggregate. Teams described collision-prone shared secrets, agents operating on human credentials with no identity of their own, and onboarding checklists that grew a new integration step per quarter. The MCP standard itself is healthy, an open protocol with broad ecosystem support, which is precisely why unmanaged proliferation is the default outcome: connecting one more source is always locally rational.

5. Dedicated maintenance cost (about 3 in 10)

The quiet one. Teams counted the headcount only after the fact: the part-time curator, the platform squad diverted from roadmap, five teams building five incompatible versions of the same thing. The bluntest summary we heard, paraphrased: an internal system like this needs permanent engineering headcount behind it, or it fails. Organizations that had done the accounting talked about homegrown context the way they talk about running their own email: possible, and mostly a way to spend senior engineers on an undifferentiated problem.

Why does "which truth wins" defeat DIY stacks?

About a third of all conversations landed, unprompted, on the same question: when two sources disagree, which one does the system believe? The wiki says the v1 endpoint retires in Q3; the chat thread moved it to Q1; the code shows it already gone. Two patterns coexist in the codebase and the agent needs to know which one is the standard, not which one is more common.

This is the problem that separates retrieval from resolution, and it is where homegrown stacks structurally give up. Similarity search returns all versions of the truth, ranked by phrasing rather than authority. Generation makes it worse: when a knowledge base contains contradictions, the model tends to fabricate a resolution rather than acknowledge uncertainty. Teams had felt this directly: two engineers getting different answers to the same question, an authoritative-sounding source sending the model down a direction that wasted a day, human opinions in chat outranking the code because they were more recent and more confident.

What makes this fatal for DIY specifically is that resolution requires signals no single team can cheaply assemble: recency with decay, code as ground truth for current behavior, and a model of who actually knows what, built from years of review and authorship activity. A few teams asked to designate subject-matter experts by hand, a reasonable patch that becomes its own stale registry within a quarter. We've compared which tools genuinely attempt conflict resolution; the short version is that almost everything in the category, homegrown or commercial, ranks results and calls it a day.

What did teams want instead?

The asks were consistent enough to read as a requirements document for the category. Ranked by rough frequency across our conversations:

Permission inheritance (close to half): answers must respect the asker's existing access, private channels, restricted spaces, contractor boundaries, without a parallel ACL system to maintain.
Automatic freshness (about a third): the stack should notice change and re-index itself; any design requiring a human to feed it was treated as disqualified on sight.
One integration point (about a third): a single connection that replaces the patchwork, the ask behind every team memory hub evaluation we see. Teams that already owned enterprise search kept asking why it was not enough; we've answered that at length, and so had many of them, empirically.
Conflict resolution with authority (about a third): not more results, a decision, with the losing source shown.
Measurable proof (about a third): benchmarks, evals, before-and-after token numbers; a business case a CFO will read. Skepticism here is earned, given that 84% of developers use or plan to use AI tools while only 29% trust what they produce.
Verifiability (about 3 in 10): citations back to sources, an audit trail, a way for a human to check the answer's work.

Notice what is absent: nobody asked for a bigger context window or a smarter model. The research agrees that the constraint is curation, not capacity: Zylos Research's January 2026 long-context benchmark found models degrade well before their claimed limits and attributed roughly 65% of 2025 enterprise AI failures to context drift, and the wanted list above is a specification for the machinery that does the curating. It maps closely to the upper levels of our context maturity framework: teams were describing, in their own vocabulary, the jump from ad hoc context to a governed, self-maintaining layer.

Where does Unblocked fit?

This is a research piece, so the pitch stays short. The findings above are, transparently, why Unblocked is built the way it is: a context engine that agents reach through one MCP server, with continuous ingestion for freshness, permission inheritance from source systems, and conflict resolution that weighs code, recency, and expertise before anything reaches a context window. It is the managed version of the thing 4 in 10 of these teams started building, minus the parts that made them stop, and unlike memory layers you bolt on and maintain yourself, nobody on your team owns the feeding schedule.

One customer, from our approved public quotes rather than these conversations, describes the day-to-day: "My biggest use of Unblocked MCP has been AI governance — searching across Slack, fourteen Notion docs, S3, trying to understand where data lives and where the gaps are. There is no other way to humanly accomplish this task. It's an absolute godsend for getting context out of sources that don't talk to each other." — Gustavo Alvarez, Software Engineer, Sixfold

Methodology

The numbers in this post come from 194 conversations held between May and August 2026 with engineering teams evaluating context tooling, representing roughly 150 distinct organizations after deduplicating repeat conversations. Organizations ranged from solo technical founders to enterprises with tens of thousands of engineers, across fintech, healthcare, security, gaming, travel, industrial, and public-sector software.

Frequencies are rounded counts of themes that surfaced organically in conversation, not answers to a fixed questionnaire, so every figure is a floor: a team with a staleness problem that never mentioned it is not counted. All figures are deliberately rounded because false precision would overstate what conversation data can support.

The selection bias matters and we want to be honest about it: every one of these teams booked a call with a context-tooling vendor. They are, by construction, predisposed to believe context is a problem worth solving, and builders hitting a wall are exactly the teams most likely to take such a call. This sample says a lot about what happens to teams that build homegrown context stacks, and nothing statistically defensible about what share of all engineering teams build one. Treat the failure-mode frequencies as well-grounded within this population and the headline build rate as an upper bound on the general one.

To protect confidentiality, no company names, verbatim quotes, or identifying details from these conversations appear here; all patterns are aggregated, and the one marked composite is an illustrative construction, not a real individual.

FAQ

Is it ever right to build your own context stack?

Yes, in narrow cases: hard data-sovereignty constraints commercial tools cannot yet meet, genuinely unusual source systems, or context infrastructure that is itself your product. Even then, the honest budget is not the build, it is the permanent staffing to keep the stack fresh, permission-correct, and conflict-aware. If the build vs buy context math only works with maintenance rounded to zero, it does not work.

How much does a homegrown context stack really cost to maintain?

Teams in our conversations rarely knew until they audited it, which is itself the finding. The visible cost is the part-time curator; the invisible costs are the diverted platform squad, duplicate builds across teams, and over-retrieval token waste at fleet scale. General software economics put maintenance at more than half of lifecycle cost, and context stacks skew worse because their core asset, organizational truth, decays continuously.

What should we measure before deciding to replace ours?

Three things, over two weeks: answer accuracy on questions you already know the answers to, staleness lag between a real change and the stack reflecting it, and tokens consumed per completed task with and without the stack in the loop. Teams that ran even informal versions of this evaluation made faster and calmer decisions than teams arguing from anecdote. A structured starting point: our AI readiness assessment.

If you're at the build-vs-buy fork

The 194 conversations behind this post suggest the fork is usually mislabeled. The real choice is not build versus buy; it is who maintains the truth. Building the retrieval pipeline is the tractable, weekend-sized part, which is why so many teams have done it. Deciding which truth wins, noticing staleness before your agents repeat it, and honoring permissions across every source is the permanent part, and it is the same problem at every company. If your homegrown context stack is in act two of the lifecycle, enjoy it, measure it, and set a calendar reminder for act three. If you are already at the wall, you are in numerically excellent company: so was roughly a third of everyone we talked to this year.

Tools That Resolve Conflicting Information Between Docs, Code, and Slack

Dennis Pilarinos — Thu, 20 Aug 2026 09:00:00 +0000

If you need a tool that resolves conflicting information between your docs, your code, and your Slack history, Unblocked is the pick, because it is the only tool in this roundup whose core job is reconciling code, pull requests, Slack threads, and docs into a single conflict-resolved answer, weighted by recency and authority signals instead of similarity scores. That claim deserves immediate qualification, though: almost nothing in this category actually adjudicates between contradictory sources. Most tools retrieve. Some aggregate. A couple ask humans to settle disputes ahead of time. Genuine machine-side adjudication is rare, and pretending otherwise would make this a useless page. So here is the honest landscape, including where each tool's model of truth comes from and where it stops.

Bottom line: aggregation puts three contradictory sources in front of you or your agent and lets you guess. Resolution decides which source to believe, says why, and shows the losing source anyway. Only one tool in this roundup treats that second step as the product; the rest either rank results, stay inside one source of truth, or delegate the adjudication to humans.

Why do docs, code, and Slack disagree in the first place?

Because each one captures a different moment in a decision's life. A doc records intent at the time of writing. Code records what actually shipped, including the compromises nobody wrote down. Slack records the moment the plan changed, usually in a thread with eleven participants and no follow-up edit to the doc. Nothing back-propagates. The Confluence page that says "we retire the v1 endpoint in Q3" stays confident long after the thread that pushed it to Q1, which is how agents end up recommending deprecated APIs with complete conviction.

The problem is compounding. Writing a document now costs nothing, so document volume is climbing while average document authority falls. When three sources disagree, an engineer applies judgment: who wrote this, when, did it ship, did anyone senior push back? An agent treats every retrieved chunk as equally true unless something upstream decides otherwise.

Why does retrieval alone make conflicts worse?

Similarity search has a structural bias toward the wrong answer. Call it the superseded-policy problem: the old policy doc is a polished, keyword-dense statement of exactly the thing you asked about, so it embeds beautifully and ranks first. The correction lives in a rambling Slack thread that mentions the policy once, obliquely, in a reply. Semantic similarity ranks the stale source above the current one almost by design, because clean prose about the topic beats messy prose about the change.

For a human skimming ten results, that is survivable. For an agent, it is fatal, because agents suffer from satisfaction of search: the first plausible hit becomes the truth they act on. A retrieval layer that returns contradictory chunks without adjudication launders stale information into confident output. This is the core reason enterprise search and a context engine are different products: one optimizes for finding, the other for deciding.

What are the tools?

Unblocked: synthesis with conflict resolution built in

Unblocked is a context engine that connects GitHub, GitLab, Slack, Microsoft Teams, Confluence, Jira, Linear, SharePoint, Sentry, Datadog, and more, and, per its documentation, "reconciles information across sources, including sources that contradict each other," answering with citations rather than a results list. Truth is decided by layered signals: code as ground truth for current behavior, recency with decay, and an expert graph built from PR and review activity that weights a statement by who made it. Agents reach the same engine through one MCP server, so the reconciliation happens before anything lands in a context window. It is the only entry here where adjudication is the headline feature, not a side effect.

Glean: broad aggregation, retrieval-ranked

Glean is the heavyweight aggregator. Its workplace search product indexes 275+ app connectors, enforces source permissions in real time, and ranks results using a knowledge graph of people, projects, teams, and processes that personalizes relevance to the asker. That is a serious retrieval system. What its public documentation does not describe is adjudication: when Confluence and Slack disagree, Glean returns both, ranked by relevance, and the reader decides. For general enterprise search that is a defensible design. For engineering truth questions, it is the gap we've written about before: ranking is not deciding.

Atlassian Rovo: Atlassian sources first

Rovo is Atlassian's play, built on its Teamwork Graph connecting teams, work, and goals. Its search combines results from Atlassian apps like Jira and Confluence with connected third-party apps such as Google Drive and Slack, and it respects source permissions. The product page emphasizes agents that automate workflows across that graph. Its docs do not describe how contradictions between sources get settled. If your engineering truth lives mostly in Jira and Confluence, Rovo's home-field coverage is real; if the correction usually lands in a PR review or a code discussion, you are outside its center of gravity.

Sourcegraph: code is the only witness

Sourcegraph takes the cleanest position by refusing the question. Its platform covers code search across every repo, branch, and code host, plus Deep Search, an AI agent that answers natural-language questions about the codebase. Sources of truth never conflict because there is exactly one: the code. That makes it a sharp answer to "what does the system do right now" and structurally silent on "what did we decide" or "why." The code can faithfully implement a decision that was reversed in a design review last week. Code-truth is necessary; it just isn't sufficient.

Guru and Notion AI: humans resolve, the tool serves

The curated-wiki model deserves fair treatment because it does resolve conflicts, just with people. Guru positions itself as a governed knowledge layer: content routes to designated experts for verification, the system flags duplicates and conflicting versions, and stale cards lose their verified status until a human re-blesses them. Notion AI runs enterprise search across Notion, Slack, Google Drive, and GitHub, with a "Verify any page" badge that surfaces in search results and AI citations. Both are honest architectures: adjudication happens at write time, by humans, on a schedule. The limit is throughput. Verification cadences work for policies and runbooks; they cannot keep pace with engineering reality that changes per merge, which is why team memory hubs drift unless curation is someone's actual job.

DIY: freshness heuristics over MCP

The build-it path: wire MCP servers for each source, stamp retrieved chunks with metadata like last-modified dates and deprecation flags, and prompt the agent to prefer fresh sources. More on why this is half a solution below.

Tool	What it aggregates	Resolves conflicts?	How truth is decided
Unblocked	Code, PRs, Slack, Teams, Confluence, Jira, Linear, docs, incidents	Yes, machine-side	Recency, expert-graph authority, review status, what shipped
Glean	275+ enterprise app connectors	No, ranks results	Knowledge-graph relevance, personalized to the asker
Atlassian Rovo	Jira, Confluence, third-party apps like Google Drive and Slack	No, ranks results	Teamwork Graph relevance within permissions
Sourcegraph	Code repositories, branches, code hosts	Sidesteps it	Code is the only source consulted
Guru	Curated cards plus connected knowledge	Flags conflicts, humans resolve	Expert verification; system detects stale and conflicting content
Notion AI	Notion, Slack, Google Drive, GitHub	Yes, by humans	Page verification badges, manual curation
DIY (MCP + heuristics)	Whatever you wire up	Partially	Freshness metadata; authority is left to the agent

How does conflict resolution actually work?

Four signals, applied roughly the way a senior engineer applies them. Recency, with decay: a Slack message from last week outweighs one from last year, but time alone settles nothing. Authority: who said it, derived from who actually builds and reviews that area of the system, not from org charts. Review status: a merged PR carries more weight than a proposal; an approved design doc more than a draft. And what shipped: when a doc and the code disagree about current behavior, the code wins, while the doc gets reframed as intent. Unblocked applies these in combination and, when a conflict cannot be cleanly resolved, surfaces both sides with a weighting rather than silently discarding the loser. That is what makes the output decision-grade rather than merely relevant.

Here is how one customer describes it in practice: "Unblocked is the first MCP queried for everything we look up. It's not just checking the code — the code could be wrong. It pulls the Confluence docs, the feature planning documents, the Slack conversations. We can't use the Slack MCP for legal reasons, so Unblocked is the only way we can access that context. For an engineering manager trying to understand a platform fast, that's the difference." — Sam Younger, Engineering Manager, UserTesting

Note the first clause: the code could be wrong. That is the whole argument against single-source truth, stated by someone living with it.

Can you build this yourself?

Partially, and the honest split matters. The freshness half is buildable. MCP gives you a standard way to connect agents to Slack, Confluence, and your repos, and nothing stops you from stamping every retrieved chunk with last-modified dates and deprecation flags so the agent can prefer newer sources. Teams do this, and it beats raw similarity search.

The authority half is the hard part, because recency is not authority. The newest message on a topic might be a wrong guess from someone who joined last month; the correction that matters might come from the engineer who has owned the service for two years. Deriving that weighting means building an expertise graph from commit and review history, with time decay and defenses against noisy contributors. Unblocked open-sourced a simplified version if you want to see the shape of the problem. Most teams instead pin truth manually in rules files, which rot on their own schedule and quietly degrade agent sessions as they drift from reality.

FAQ

What's the difference between aggregation and conflict resolution?

Aggregation collects sources into one search surface and ranks them; the reader reconciles contradictions. Conflict resolution compares the retrieved sources against each other and applies recency, authority, and shipped-state signals to decide which claim stands, before the answer is composed. Most "all your knowledge in one place" tools do the first and market adjacent to the second.

Can ChatGPT or Claude with connectors resolve conflicting sources?

Not reliably. Connectors hand the model raw results from each source, and the model adjudicates with whatever is in its context window: no expert graph, no review-status signal, no decay model. It will often pick the most confidently worded chunk, which favors polished stale docs over messy current threads.

Do knowledge graphs resolve conflicts automatically?

No. A knowledge graph relates entities, which improves retrieval and disambiguation, and both Glean and Atlassian build on one. Relating a doc to a thread is not the same as ruling on which is correct; that ruling requires an explicit adjudication layer on top of the graph.

How do agents know when a doc is stale?

On their own, they don't; a five-year-old page and yesterday's page arrive as identical text. Staleness has to be computed upstream, from timestamps at minimum, and ideally from whether later PRs, decisions, or conversations superseded the content.

Which truth wins in your stack today?

Run the test on your own system: pick a question your team has actually relitigated, something where the doc, the code, and the Slack thread genuinely diverge, and ask it through whatever your agents currently use. If you get three sources and a shrug, you have aggregation. If you get one answer with reasons and citations, including the source that lost, you have resolution. Unblocked is built for the second outcome; that is the difference this entire category turns on.

Why Wouldn't Claude Code Handle Your Org Context Itself?

Dennis Pilarinos — Wed, 19 Aug 2026 10:00:00 +0000

The scene repeats in almost every evaluation we sit in on. Three weeks into a Claude Code rollout, the pilot team is happy, and someone proposes adding a context engine. The CTO looks up from the deck and asks, near-verbatim: "Why wouldn't Claude solve this problem? Why would we need a third-party solution?"

It's the right question, and it deserves a straight answer rather than a vendor dodge. So here it is. Claude Code is genuinely closing context gaps: CLAUDE.md, auto memory, subagents with their own memory, skills, MCP. For a solo developer on one repository, the built-ins are often enough, and we'll say so explicitly below. What Claude Code structurally won't become is the org-wide, cross-tool, permission-aware synthesis layer, because that's infrastructure, not an agent feature. An agent reads context. Something still has to decide what's true across 50 repositories, Slack, Jira, and Confluence, for every agent and every engineer, with permissions enforced. Whether Claude Code needs a context tool comes down to whether that job exists at your scale. Let's take it apart honestly.

What can Claude Code already do about context?

More than most third-party pitches admit. Per the living Claude Code memory docs, CLAUDE.md files now carry persistent instructions at four scopes: an org-wide managed policy file IT can deploy via MDM, user-level preferences, project files shared through version control, and gitignored local overrides. A .claude/rules/ directory splits instructions into topic files, and rules can be path-scoped so they only load when Claude touches matching files. Auto memory lets Claude write its own notes per repository, loading the first 200 lines or 25KB of its MEMORY.md index into every session, with topic files read on demand. Skills package procedures that load only when invoked. Subagents can maintain their own persistent memory. And MCP connects the agent to Jira, Sentry, Postgres, or anything else speaking the protocol. If your mental model is one flat CLAUDE.md fighting for context window space, it's a year out of date. Any honest case for a context tool has to start from this baseline, not a strawman.

Key Takeaways

Claude Code's built-ins (CLAUDE.md, auto memory, rules, skills, MCP) handle per-user, per-repo context well; a solo dev on one repo often needs nothing else.
The built-ins stop at team truth: auto memory is machine-local, rules files are hand-maintained per repo, and the docs warn that Claude may pick between contradictory rules arbitrarily.
The organizational context layer is vendor-neutral infrastructure; Pragmatic Engineer's 2026 survey found 70% of engineers run 2-4 AI tools at once, and every one of them needs the same answers.
A context engine adds what no single agent will ship: cross-source synthesis, conflict resolution, and permission enforcement across all your systems and all your agents.

Where do the built-ins stop?

At the boundary between one engineer's setup and the organization's truth. Auto memory is explicitly per-machine: the docs state files "are not shared across machines or cloud environments," so the lesson Claude learned debugging your teammate's flaky ingestion job never reaches your session. CLAUDE.md is per-repo and hand-maintained; across 50 repositories that's 50 files that rot independently and need syncing against AGENTS.md and .cursorrules besides. There's no conflict resolution: the docs warn that when two rules contradict each other, "Claude may pick one arbitrarily." And there's no cross-source permission model. Each MCP server is its own credential with its own access rules; nothing checks whether the engineer driving the agent should see what a connector returns from another system. That's the Claude Code organizational context problem in one sentence: every mechanism is scoped to a user, a machine, or a repo, while the truth you need is scoped to the org. The agent re-derives that truth from scratch every session, at inference time, and gets it differently each run. Rules files can't close that gap by getting longer.

Won't Anthropic just build this?

They'll keep building, and the built-ins will keep improving; betting against that would be foolish. But look at what they ship: managed CLAUDE.md, subagent memory, an /init that reads your Cursor and Copilot rules, an /import that carries over a whole agent config. Every feature makes Claude Code better at consuming context. None of them makes Claude Code the arbiter of organizational truth, because that layer is vendor-neutral infrastructure and your org isn't single-vendor. Pragmatic Engineer's March 2026 tooling survey of 900+ engineers found 70% use two to four AI tools simultaneously, and 15% use five or more. JetBrains' January 2026 data shows Copilot, Cursor, and Claude Code splitting workplace usage 29/18/18. Your team runs Claude Code and Cursor and CI review agents today, and will run something else in eighteen months. The layer that knows what's true has to outlive any one agent choice, the way your identity provider outlives any one SaaS app. Anthropic optimizing that layer for Claude alone would make it worse at its actual job. That's why team memory belongs in a hub, not an agent.

What does a context engine actually add?

This is where Unblocked sits: institutional context for coding agents, built as infrastructure rather than as a feature of any one of them. A context engine ingests your repos, Slack, Jira, Confluence, support knowledge base, and docs continuously, resolves aliases and contradictions at ingestion time, and serves synthesized, cited, permission-enforced answers to any agent that asks, over a single MCP connection. The agent stops being the integration layer; the organizational knowledge layer does the assembly before a token hits your context window. One customer put it better than we can:

"You cannot make coding agents work without domain and functional context. We connected and trained Unblocked on our Code repos, Atlassian tools, Internal docs, Product Documentation, KB from Support and Slack history. When an agent asks a question, it gets the full picture — not just the code analysis, but also why decisions were made and what the constraints are. Other tools like Copilot know only the code. That's limited value. Unblocked is a game changer for Coding Agents."

— Raphael Bres, CTO, Tradeshift

Note what he connected: six source families, exactly the surface no per-repo file reaches. And note the phrase "when an agent asks," singular mechanism, plural agents: the same engine answers Claude Code, Cursor, and whatever runs in CI, identically, with each requester seeing only what its human is entitled to see. That's what it means to give Claude Code organizational context instead of asking it to reconstruct some approximation per session.

When are the built-ins genuinely enough?

Honestly: often. If you're a solo developer, or a small team living in one repository with decisions that fit in a couple hundred lines of CLAUDE.md, you don't need us. Keep a tight project CLAUDE.md, let auto memory accumulate what it learns, add a well-chosen MCP server or CLI tool for the one external system you touch, and revisit when something breaks. Even dedicated memory MCP servers are overkill at that scale. The trouble starts on predictable thresholds: multiple repos with shared conventions, decisions living in Slack threads and Jira comments instead of the repo, engineers whose agents answer differently because their private memories diverged, or a compliance team asking who can retrieve what. A useful tell: count how often an agent's answer gets corrected in review with information that existed somewhere but not in the repo. Once that's weekly, the gap is organizational, not personal. Below those thresholds, saying Claude Code needs a context tool would be selling you something. Above them, the built-ins aren't failing; they were never scoped for the job, and no amount of CLAUDE.md gardening rescopes them.

FAQ

Is CLAUDE.md enough organizational context for Claude Code?

For one repo and one team, usually yes. It stops scaling when conventions span repositories, when the reasoning behind decisions lives in Slack and Jira rather than in files anyone maintains, and when contradictions accumulate that nothing resolves. A checked-in file records what someone remembered to write down; institutional memory is mostly the things nobody did.

Can MCP servers give Claude Code organizational context on their own?

They give it access, which is different. A Slack MCP returns Slack messages; a Jira MCP returns tickets. Your agent still does the cross-source assembly at inference time, on your token bill, guessing at project nicknames it has never seen and not knowing which of two conflicting answers is current. Connectors are the transport for organizational context, not the source of it. The synthesis has to happen somewhere, and an agent's context window is the most expensive possible place.

Does a context engine replace CLAUDE.md or auto memory?

No. Keep CLAUDE.md for repo-specific instructions and auto memory for personal working notes; they're good at that, and the docs keep making them better. When people ask whether Claude Code needs a context tool, they usually picture a replacement. It's a foundation: the shared, permission-aware layer the per-repo files silently assume, the thing that knows what the org actually decided, across every repo and every tool, for every agent and engineer.

The one-question test

When the question comes up in your own eval meeting, you don't need our framing or Anthropic's roadmap. Ask one thing: when two sources disagree about how your systems work, what decides which one the agent believes? If the answer is "the engineer notices and fixes it," you're describing the per-repo world, and Claude Code's built-ins will carry you for a while. If the answer needs to hold across 50 repos, four tools, and 200 engineers with different access rights, you've just specified infrastructure: ingestion, synthesis, conflict resolution, permission enforcement, and citations so a human can audit the answer. That spec doesn't shrink because the agent got smarter. And the agent can't grant it to itself, any more than an app can be its own identity provider. So the CTO's question has a clean answer after all. Anthropic will keep making the agent better at reading context, and you should use every bit of it. Someone still has to decide what that context says, and make your organization legible to every agent you'll ever run.

Is Glean Good Enough for Engineering Questions? An Honest Assessment

Dennis Pilarinos — Tue, 18 Aug 2026 09:30:00 +0000

Your company already pays for Glean, the rollout went fine, and now engineering is asking for budget for a separate knowledge tool. Someone on the eval committee asks the question this post exists to answer: is Glean good enough for engineering, or does the team actually need something built for it?

The verdict: for general enterprise search across a whole company, Glean is genuinely good and often enough. For engineering-specific questions, meaning codebase behavior, architecture decisions, and why the code is the way it is, Glean hits structural limits that no amount of configuration fixes. Those limits aren't bugs or missing connectors. They come from what enterprise search fundamentally is: a retrieval system over documents, applied to a domain where the answer is rarely inside any single document.

The short version: keep Glean for company-wide search, where it earns its seat. Treat engineering knowledge as a separate problem, because the properties that make a tool great at finding documents are not the properties that make it good at explaining a codebase.

What is Glean actually good at?

Quite a lot, and pretending otherwise would make the rest of this assessment worthless. Glean connects most of the enterprise stack through native connectors, push APIs for custom or self-hosted systems, and partner-built integrations (Glean docs). Its permission story is real engineering: connectors fetch each source's permission map so results only show a user what they can already see in the source application (Glean docs). That is harder than it sounds, and many homegrown search projects die on exactly that rock.

Its AI Answers feature returns permission-aware responses with citations, and Glean documents that identical queries produce deterministic results (Glean docs). For the HR policy lookup, the sales enablement doc, the security questionnaire answer buried in Drive, Glean is a legitimately strong product with a mature compliance posture. If your evaluation is about knowledge workers broadly, you can stop reading and keep it.

Where does it break for engineering teams?

The problems start when the question is about a living system rather than a stored document. A sales deck from March is still true in August; the code from March is three refactors gone. That single difference in the underlying material drives four limits that show up repeatedly when teams try to use Glean for engineering knowledge, and none of them is fixable with more connectors or better prompt hygiene.

How code-aware is the index?

Glean's GitHub connector indexes repositories, source files, commits, READMEs, issues with comments, and pull requests with reviews and diffs (Glean docs). That sounds comprehensive, but note what it is: code stored as text documents. Glean itself describes its assistant as retrieving indexed content and generating responses from it, drawing on company knowledge, web knowledge, and the LLM's training (Glean docs). Retrieval over text chunks is a reasonable model for prose. Code is not prose. Understanding it requires structure: what calls what, which service owns which behavior, how a function changed across releases. A keyword-relevant chunk of a 4,000-line file is not an answer to "how does billing retry work."

Can the index keep up with daily code change?

Credit where due: Glean's GitHub freshness is decent, with incremental crawls every 10 minutes and webhook-based updates (Glean docs). But freshness varies by connector, with full crawls ranging from 6 hours to 28 days, and missed deletion events wait for the next full crawl (Glean docs). Initial deployment takes two to three days of crawling for a small org, 10 to 14 for a large one, plus another 2 to 14 days of ML training before Glean says you should let users in at all (Glean docs). And one operational gotcha: until each engineer individually completes a GitHub OAuth step, no GitHub content appears in their results at all (Glean docs). Teams discover that one ticket at a time.

Do you get an answer or a reading list?

Enterprise search returns ranked documents; the synthesis burden stays with the engineer. Glean's AI Answers narrow this gap for questions whose answer lives inside one or two retrievable documents. Engineering questions rarely do. "Why do we run two payment providers?" is answered by a 2023 PR review thread, a Slack argument, an ADR that was half-updated, and a Jira ticket that contradicts the ADR. Ten relevant hits with citations is still homework. Worse, when sources conflict, ranking is not resolution; we wrote about why in how tools handle conflicting context and in context engine vs enterprise search.

Where did the "why" go?

Glean's retrieval is also personalized: results are shaped by what each user has access to and interacts with, so answers can differ across users (Glean docs). For document search that is a feature. For engineering truth it is a liability, because "why is the auth service structured this way" has one correct answer regardless of who asks. The why lives in the connective tissue between artifacts, the thing search engines index as separate documents and never join. This is the same gap that hobbles coding agents, which we covered in what your coding agent can't see.

Is Glean's AI enough for codebase Q&A?

For orientation questions, sometimes. "Where is the deployment runbook" or "who owns the notifications service" are retrieval problems, and Glean handles retrieval well. The harder class of question is the one that sends an engineer spelunking through git blame: what does this actually do in production, and is the doc describing it still true? The gap appears at the trust boundary. Stack Overflow's survey data shows 84% of developers using or planning to use AI tools while only 29% trust the output's accuracy, down 11 points from 2024, largely because verifying plausible-but-wrong answers costs as much as doing the work yourself (Stack Overflow, 2026). A RAG answer assembled from whichever chunks ranked highest, personalized per user, over sources that may disagree with each other, is exactly the kind of output senior engineers double-check. Once every answer needs verification against the codebase, the tool has become a suggestion box. Glean for engineering ends up trusted for finding things and distrusted for explaining them, which is a rational response to its architecture, not a rollout failure.

When is Glean genuinely the right choice?

An honest evaluation names the cases where the answer is "keep Glean and stop there." There are several:

Your pain is company-wide findability, not engineering comprehension. If engineers mostly ask "where is the doc," not "why is the code like this," Glean covers it.
Engineering is a small share of the org. A 40-person engineering team inside a 3,000-person company may not justify a second platform until agent adoption forces the issue.
Your codebase knowledge is unusually well-documented. Teams with disciplined, current ADRs feel this gap less, though in our experience they are rare, and homegrown context stacks built to compensate have their own carrying costs.
You need one tool for legal, sales, support, and engineering. No engineering-native platform tries to be that, and Glean is one of the better answers to it.
Procurement reality. If a second vendor review will take two quarters, deploying Glean's GitHub connector today beats a better tool you can't buy yet, and nothing about doing so forecloses adding an engineering platform later.

If two or more of those describe you, the honest read of "is Glean good enough" is yes, for now. Revisit when your engineers or their agents start asking questions the index can't answer.

What do engineering-first alternatives do differently?

The alternative category isn't "better search." It's a context engine: a system that ingests code, PRs, Slack, tickets, and docs, then reasons across them to produce one synthesized, cited answer instead of a ranked list. Unblocked, the engineering-native context engine we build, connects GitHub, GitLab, Slack, Teams, Confluence, Jira, Linear, and more, and explicitly reconciles sources that contradict each other before answering (Unblocked docs). It serves that answer wherever the question happens: IDE and coding agents over MCP, pull requests, Slack, CLI, web. The same institutional-memory layer that answers engineers also feeds agents, which is why teams pair it with tools like Claude Code; see giving Claude Code institutional memory.

Here's how one customer describes the difference in practice: "Unblocked is game-changing for information availability. Most AI tools are siloed. This one connects all of our documentation across the disparate systems to give answers we trust." — James Ford, Principal Engineer for Developer Experience, Compare the Market

For head-to-head detail, see Unblocked vs Glean, the three-way Unblocked vs Glean vs Augment, and the broader field in Glean alternatives.

FAQ

Can Glean search code?

Yes. Its GitHub connector indexes source files, commits, issues, and PRs with reviews and diffs, across common code and text file types, though wikis and GitHub Pages content aren't indexed by default (Glean docs). Searching code as text is the easy half; the hard half is answering questions about behavior and history, which retrieval alone doesn't do.

Is Glean good enough for a small engineering team?

Often, yes. If the team's questions are mostly findability and the org already runs Glean, the marginal pain may not justify a second tool yet. The tipping points are AI agent adoption and codebase archaeology becoming a daily activity.

Does replacing Glean make sense, or do teams run both?

Most engineering teams we see run both: Glean as company-wide search, an engineering knowledge platform for codebase Q&A and agent context. They solve different problems, so this is complement, not rip-and-replace. Our engineering knowledge platform roundup covers how the categories split.

What should we test during a Glean-for-engineering trial?

Ask questions whose answers span systems: "why did we pick this queue," "what broke last time we touched checkout," "which of these two docs is current." Score whether you got a defended answer or a list of links. Our AI tools for engineering teams guide includes more evaluation prompts.

How to decide in one afternoon

Skip the six-week bake-off. Collect the last ten real questions engineers asked in Slack that took a senior person to answer. Run all ten through Glean and through an engineering-native platform. Grade each response on three axes: did it synthesize one answer or return links, did it cite sources you could check, and did it explain why the system is the way it is rather than just where something lives. Glean will win the pure findability questions, and that result is worth respecting. If the why-questions come back as reading lists, you have your answer on whether Glean for engineering is enough, and it took an afternoon instead of a quarter. Whichever way it lands, you'll have decided on evidence from your own codebase rather than anyone's pitch deck, ours included.

The Snowflake Copilot Autofix Incident: An AI Approved Removing a Guardrail Nobody Told It About

Dennis Pilarinos — Mon, 17 Aug 2026 23:22:02 +0000

Originally published at getunblocked.com on August 17, 2026.

On June 18, 2026, a routine-looking pull request merged into snowflake-connector-net, Snowflake's public .NET driver repository. PR #1218, "SNOW-2069227: Update jira workflows," reworked the repository's Jira automation, and it carried a co-author trailer that would later make headlines: "Copilot Autofix powered by AI." Somewhere in that refactor, the existing sanitized-input pattern in the jira_issue.yml GitHub Actions workflow disappeared, replaced by direct string interpolation in a run: block. For five days, any GitHub user with a crafted issue title could execute commands inside Snowflake's CI.

On June 23, Wiz Research's autonomous "Red Agent" found the flaw while scanning Snowflake's GitHub organization, built a working exploit, and pulled a Jira API token through an out-of-band callback. Wiz reported it through Snowflake's HackerOne program that day. Snowflake patched it the same day, rotated the token on June 24, and its investigation found no evidence of unauthorized access. The full writeup went public on August 17.

In brief: The Copilot Autofix Snowflake incident isn't a story about reckless AI. A refactor removed a sanitization pattern nobody remembered the reason for, an AI reviewer and a human reviewer both approved it, and an AI security agent exploited the gap five days later. The failure was missing context, not too much automation.

What actually happened?

The refactor reworked how the repository's workflows talked to Jira, and along the way jira_issue.yml lost its safe input handling. The old workflow passed the issue title through an env: variable and built its JSON payload with jq --arg, so untrusted text never touched the shell parser. The new version interpolated ${{ github.event.issue.title }} straight into a run: block. One single quote in an issue title and you're out of the echo string, running arbitrary commands on the runner.

A guard condition made it worse by looking effective. The workflow checked github.event.pull_request.user.login, a field that's always null on issue events, so the check blocked nobody. When Wiz's Red Agent scanned the repo on June 23, it spotted the pattern, hit a shell syntax error on its first attempt, analyzed the failure, adjusted its payload, and exfiltrated the Jira token for qa@snowflake.net. That token had read access to Snowflake's engineering, security compliance, and bug bounty projects. Wiz deleted everything it accessed, and Snowflake's audit review found no other third party had touched the endpoint during the five-day window.

What was Copilot Autofix's actual role?

Here's where early headlines got ahead of the facts. The commit carries a Co-authored-by trailer for "Copilot Autofix powered by AI," and initial coverage read that as the AI writing the vulnerable change. Wiz has since updated its post to clarify: Copilot Autofix checked the merged PR and code change and identified it as all-clear without noticing the critical vulnerabilities. Whether the deletion itself was AI-assisted is unclear; The Hacker News reports the bot's direct modification was to jira_close.yml, while a Snowflake engineer authored the jira_issue.yml change.

The correction sharpens the lesson rather than softening it. GitHub's own docs are candid that Autofix "may suggest fixes that fail to remediate the underlying vulnerability or introduce new vulnerabilities," and that every suggestion requires explicit developer review. In the Copilot Autofix Snowflake timeline, the AI in the loop wasn't a rogue author. It was one of the review tools in the pipeline, and it blessed a change it had no reason to distrust.

Why did review miss it?

Because everyone reviewing it, human and machine, was judging the diff on its face. The env: plus jq indirection is exactly the mitigation GitHub's security hardening guide prescribes for untrusted input, which strongly suggests it was there on purpose. But nothing in the diff said so. No comment, no linked decision, no trace of whoever added it or why. That's Chesterton's fence, agent edition: the fence got removed because nothing in anyone's context explained what it was holding back.

To a reviewer who only sees the diff, deleting that indirection reads as simplification: a cleaner script with fewer moving parts. The stated goal of the PR was modernization, and against that goal the change looks like progress. Commenters on Hacker News were honest about it: "I probably would have made the same mistake." The change was context-blind, and so was the review of it. Agents can't see what isn't in their context, rules files rot, and models confronted with a gap will fill it with something plausible. Plausible is what got merged.

What would context-aware review have seen?

The history the diff couldn't show. Somewhere in the repository's past sits the change that introduced the env:/jq pattern, and, if it was deliberate, whatever hardening pass or review discussion put it there: the moment someone decided issue titles should never touch a run: block directly. A reviewer with access to that history could have seen the deletion not as a simplification but as a guardrail coming down, and asked why it was safe to remove.

This is the case for context-aware code review, and it's what we build at Unblocked: an institutional-memory layer for PR review that surfaces the decisions behind the code, pulling decision-grade context from PRs, docs, and team chat into the moment a change is judged. One of our customers put it plainly:

"LLMs are only as good as their context, and code alone gives them a narrow view — the codebase is always behind where the team wants to go. When I plugged Unblocked into our context-gathering and PR review steps, it brought in the Slack conversations where real architectural decisions get made. We went from three rounds of PR review to one before the code was production-ready." — Pablo Vallejo, Engineering Manager, Clio

Review that remembers why is review that can catch a deleted fence.

What should teams change this week?

The most transferable Copilot Autofix Snowflake lessons are mechanical. Run a workflow auditor like zizmor in CI; its template-injection audit flags exactly the ${{ }}-in-run: pattern that burned Snowflake. Enforce GitHub's intermediate-environment-variable rule for anything derived from github.event, and test your guard conditions against the events they actually fire on, since a check that references a nonexistent field fails open.

Then fix the context layer, because linters only catch known patterns. Treat AI-co-authored changes to security-relevant files, workflows, auth code, and input handling as a signal to review harder, not a reason to skim. Agents confidently ship changes their training and context can't justify, whether that's calling deprecated APIs or deleting sanitization, and the burden of catching that lands on review. Finally, when you remove code that looks like defensive indirection, make the PR say why it's safe to remove. And wire your reviewers, human and AI, to a source of truth that includes decision history, so "why does this exist?" gets answered before the merge button, not after the disclosure.

FAQ

Did Copilot Autofix write the vulnerable code?

It's unclear, and Wiz says so explicitly in its updated post. What's documented: the merged commit lists Copilot Autofix as a co-author, the bot's direct modification appears to be jira_close.yml, a Snowflake engineer authored the jira_issue.yml change, and Autofix reviewed the result and raised no alarm. Attribution aside, the operative fact doesn't change: both the AI review path and the human review path looked at the removal of a working guardrail and approved it.

Was Snowflake customer data exposed?

There's no evidence of it. The token at the center of the Copilot Autofix Snowflake exposure granted read access to internal Jira projects, not the Snowflake data platform. Snowflake patched the same day it was notified, rotated the token the next day, and stated its investigation "found no evidence of unauthorized access." Audit review showed Wiz was the only third party on that endpoint during the exposure window, per The Register.

Would a static analysis tool have caught this?

Almost certainly. Tools like zizmor and actionlint detect template expansion of untrusted context values in run: blocks, and Hacker News commenters made the same point: writing GitHub Actions without static analysis is asking for exactly this. Notably, the vulnerable pattern is the textbook example in GitHub's own hardening guide, so the detection rules are mature. But linters wouldn't have explained why the old pattern existed, and they won't flag the next guardrail that doesn't match a known signature. Pattern-matching catches the known footguns; context catches the fences.

The uncomfortable symmetry

An AI waved this bug into production and an AI dug it back out, and the difference between them wasn't capability but what each one knew. Red Agent arrived with an adversarial mission, deep knowledge of injection patterns, and the persistence to iterate when its first exploit threw a syntax error. Autofix reviewed a diff with no knowledge of why the old code was shaped the way it was, no memory of the review that shaped it, and no reason to ask. Same class of model, opposite outcomes, entirely determined by context.

Snowflake, for its part, handled the incident the way you'd want: same-day patch, next-day token rotation, cooperative disclosure, and a public commitment to share the lessons. None of that is a reason to pull agents out of your pipeline. The lesson of the Copilot Autofix Snowflake incident is that every reviewer you add, silicon or human, is only as good as the history you give it. Give your review process the memory your repo doesn't have.

CLAUDE.md vs AGENTS.md vs .cursorrules: Which File Should You Write?

Dennis Pilarinos — Fri, 14 Aug 2026 15:00:00 +0000

Write AGENTS.md, add a one-line CLAUDE.md bridge if you run Claude Code, and stop writing .cursorrules. That is the 2026 answer for most teams, and it comes down to reach. AGENTS.md is the open format stewarded by the Agentic AI Foundation under the Linux Foundation, and more than 60,000 open-source projects already use it. So do over 20 tools, including OpenAI Codex, Cursor, GitHub Copilot's coding agent, Gemini CLI, Windsurf, and Zed. The claude.md vs agents.md question has one real wrinkle, though: Claude Code does not read AGENTS.md natively, and Cursor has declared its original rules file legacy. This guide covers choosing a file; syncing, auditing, and conflict precedence each have their own pages, linked where they come up.

What Are CLAUDE.md, AGENTS.md, and .cursorrules?

CLAUDE.md is Anthropic's memory file for Claude Code: plain markdown instructions loaded at the start of every session, treated as context rather than enforced configuration, per the Claude Code memory docs. It supports four scope levels, from an organization-wide managed policy file down to a personal, gitignored CLAUDE.local.md.

AGENTS.md is the cross-vendor open standard, described on the agents.md spec site as "a README for agents." It is standard markdown with no required fields, and agents "automatically read the nearest file in the directory tree, so the closest one takes precedence."

.cursorrules is Cursor's original single-file format, and Cursor's own docs are blunt about it: "The .cursorrules file in your project root is legacy and will be deprecated." Its successor is the .cursor/rules directory of .mdc files, so the honest three-way comparison in 2026 is CLAUDE.md vs AGENTS.md vs the .cursor/rules directory.

Key Takeaways

AGENTS.md is the cross-tool standard: stewarded by the Agentic AI Foundation under the Linux Foundation, used by more than 60,000 open-source projects, and read natively by Codex, Cursor, Copilot's coding agent, Windsurf, Zed, and over a dozen more.
Claude Code reads CLAUDE.md, not AGENTS.md; the documented bridge is a one-line @AGENTS.md import, a symlink, or the /import command in v2.1.213 and later.
.cursorrules is legacy per Cursor's own docs; new rules belong in .cursor/rules as .mdc files, which add glob scoping and four rule types.
All three files are static snapshots of your conventions; picking the right filename does not stop the contents from going stale.

CLAUDE.md vs AGENTS.md vs Cursor Rules: How Do They Compare?

The table below compares the three formats on the dimensions that actually change your day: where the file lives, who reads it, how it nests, and how much you can put in it. Every cell traces to the vendor docs cited throughout this post: Anthropic's memory docs, the agents.md spec, and Cursor's rules docs.

Dimension	CLAUDE.md	AGENTS.md	Cursor rules
File name and location	CLAUDE.md at repo root or in .claude/, plus a user-level file, managed-policy paths, and CLAUDE.local.md	AGENTS.md at repo root, with nested files per subproject	.cursor/rules directory of .mdc files; legacy single .cursorrules at root
Owner or steward	Anthropic	Agentic AI Foundation under the Linux Foundation	Cursor
Agents that read it natively	Claude Code; Copilot agents also honor it at repo root	20+ tools including Codex, Cursor, Copilot coding agent, Windsurf, Zed, Devin, Warp, Aider, and Amp	Cursor only
Format	Plain markdown; block-level HTML comments stripped before load	Plain markdown, no required fields	Markdown plus YAML frontmatter (description, globs, alwaysApply)
Nesting and hierarchy	Four scope levels; walks up the directory tree; subdirectory files load on demand	Nested files, nearest wins; Codex merges home, repo root, then working directory	Nested rules directories; Team, then Project, then User rules
Imports and composition	Imports via @path syntax, up to four hops deep	None in the spec; tool-dependent	Remote rules importable from GitHub repositories
Scoping	Path glob frontmatter on rules in .claude/rules/	None; position in the tree only	Four rule types including file-pattern matching and description-based selection
Size guidance	Target under 200 lines per file	32 KiB combined default budget in Codex	Keep rules under 500 lines
Team sharing	Version control plus managed-policy deployment via MDM	Version control	Version control plus dashboard-managed Team Rules on Team and Enterprise plans
Ecosystem momentum	Anthropic-specific, though honored at root by Copilot agents	60,000+ open-source projects; the emerging standard	.cursorrules is legacy; the .mdc format is Cursor-proprietary

The pattern: AGENTS.md wins on reach, Cursor rules win on scoping precision, and CLAUDE.md wins on hierarchy depth and imports for Claude-first teams. All three vendors publish size ceilings in the hundreds of lines; if you are over, here is how to audit a bloated CLAUDE.md.

Which Agents Read Which File in 2026?

Only one mainstream agent holds out on the standard file, and it is Claude Code. Here is the support matrix as of August 2026, verified against vendor docs.

Agent	CLAUDE.md	AGENTS.md	.cursor/rules or .cursorrules	Its own file
Claude Code	Yes	No; bridge with an import or symlink	No; the /init command can mine them into CLAUDE.md	CLAUDE.md is its own file
OpenAI Codex	No	Yes; merges home, repo root, then working directory under a 32 KiB default budget	No	AGENTS.override.md variants
Cursor	No	Yes, at root and in subdirectories	Yes; .cursorrules still read but legacy	.cursor/rules .mdc files
GitHub Copilot	Yes, at repo root	Yes, nearest file wins	No	.github/copilot-instructions.md plus path-scoped .instructions.md
Gemini CLI	No	Via the context.fileName setting	No	GEMINI.md by default
Windsurf	No	Yes, in any directory	No	.devin/rules preferred, .windsurf/rules as fallback, legacy .windsurfrules still read

Three of these rows contradict most existing comparisons. First, Anthropic's docs are explicit: "Claude Code reads CLAUDE.md, not AGENTS.md." The documented bridge is a CLAUDE.md whose first line is @AGENTS.md, a symlink, or the /import command in v2.1.213 and later. We run that import in this very repo, and /context confirms the file loads under Memory files. Second, GitHub Copilot honors five instruction filenames: .github/copilot-instructions.md, path-scoped .instructions.md files with applyTo globs, AGENTS.md anywhere with nearest-wins precedence, and CLAUDE.md or GEMINI.md at repo root. Third, Gemini CLI defaults to GEMINI.md but reads AGENTS.md if you list it under context.fileName in settings.json. The Windsurf row traces to Windsurf's own docs, now under Cognition's Devin documentation: AGENTS.md files are read in any directory of the workspace, and the native rules home has moved to .devin/rules, with .windsurf/rules kept as a fallback. When these files disagree in one repo, see which file wins when they disagree.

How Do Hierarchy, Imports, and Scoping Differ?

This is where the formats genuinely diverge in capability rather than filename. CLAUDE.md has the deepest machinery: a four-level load order from managed policy down to CLAUDE.local.md, subdirectory files that load on demand, @path imports that resolve up to four hops deep, and a .claude/rules/ directory where YAML paths: frontmatter scopes a rule to matching globs.

AGENTS.md is deliberately minimal: plain markdown, nested files with nearest-wins precedence, nothing else in the spec. Tools layer behavior on top; Codex concatenates files from your home directory, repo root, and working directory, stopping at a 32 KiB default budget (project_doc_max_bytes), and it honors AGENTS.override.md files for local overrides plus a config option that adds fallback filenames.

Cursor sits in between. Each .mdc rule declares one of four types: apply always, apply to specific files on a glob match, apply intelligently based on the rule's description, or apply manually. Rules nest in subdirectories; Team and Enterprise plans add dashboard Team Rules that outrank project rules. The ecosystem is converging on the same ideas (hierarchy, glob scoping, imports) and implementing them in incompatible ways.

Which File Should You Write in 2026?

The CLAUDE.md vs AGENTS.md vs .cursorrules verdict from the top, restated as scenarios:

Multi-tool team, the 2026 default: write AGENTS.md as the canonical file and add a one-line CLAUDE.md bridge. Already running all three? The mechanics live in keeping CLAUDE.md, AGENTS.md, and .cursorrules in sync.
Claude Code-only team: write CLAUDE.md natively. You gain imports, path-scoped rules in .claude/rules/, and managed-policy distribution that no other format matches.
Cursor-heavy team that needs glob-scoped rules: put scoped rules in .cursor/rules and the shared baseline in AGENTS.md; Cursor reads both.
Anyone still on .cursorrules: migrate now. The vendor calls the format legacy, and the migration is a copy-paste into one always-apply rule.

Whichever row you land on, remember that you have chosen a container for conventions, and the contents still need someone to keep them true. Pick for reach today; Linux Foundation stewardship also makes AGENTS.md the safest bet for a file you will still be maintaining in two years. What no pick solves is the maintenance itself, which is where the last part of this post goes.

Frequently Asked Questions

Should I use CLAUDE.md or AGENTS.md?

In the CLAUDE.md vs AGENTS.md decision, reach settles it: use AGENTS.md if more than one tool touches the repo, and use CLAUDE.md if Claude Code is your only agent or you need its imports, path-scoped rules, or managed-policy deployment. The two coexist cleanly: a CLAUDE.md containing the single line @AGENTS.md gives both audiences the same instructions.

Does Claude Code read AGENTS.md?

No. Anthropic's memory documentation states that Claude Code reads CLAUDE.md, not AGENTS.md, which contradicts several popular comparison posts. The documented bridges are a one-line @AGENTS.md import, a symlink from CLAUDE.md to AGENTS.md, or the /import command available since v2.1.213.

Is .cursorrules deprecated?

Effectively, yes. Cursor's docs say the file "is legacy and will be deprecated." It is still read today for backward compatibility, but the migration path is official: move the content into a .cursor/rules .mdc file set to always apply, then delete .cursorrules.

Can one rules file work for all agents?

Nearly. AGENTS.md plus a one-line CLAUDE.md bridge plus one Gemini CLI config line covers the mainstream 2026 stack: Codex, Cursor, Copilot, Windsurf, Claude Code, and Gemini CLI. What one file cannot do is stay current on its own, which is the real limit of this whole category.

Where Does the Rules-File Approach Run Out?

Everything above answers which file to write. None of it fixes what the file is: a snapshot someone hand-edited, and it started going stale the moment it was saved. The 2026 evidence cuts both ways. A study of 124 pull requests across 10 repositories found AGENTS.md presence associated with a 28.64% lower median runtime and 16.58% lower output token consumption. But a second 2026 evaluation found repository context files raised inference cost by over 20% on average without improving task success. And a study of 2,853 GitHub repositories found context files are often the sole context mechanism a repository uses. The format war is about the filename; the failure mode is the file's freshness, and no filename fixes that. Why the contents decay is covered in why rules files rot, and whether to keep investing in files is the subject of rules files vs a context engine. Rules files tell agents what you remembered to write down; a context engine like Unblocked surfaces what you didn't, serving every agent the current answer over MCP instead of a per-tool snapshot.

Pick One File, Then Stop Writing Rules

For most teams: AGENTS.md canonical, CLAUDE.md as a one-line bridge, .cursorrules deleted. The concrete steps:

Create AGENTS.md at repo root, under 200 lines of stable, non-discoverable facts: build commands, conventions, the things an agent cannot infer from code.
Bridge Claude Code with a CLAUDE.md whose first line is @AGENTS.md.
Migrate .cursorrules into .cursor/rules, or delete it if AGENTS.md now covers it.
Resist moving anything that changes weekly into any of these files. All three answer the same question, namely what was true the day someone last edited them; a context engine answers what is true now.

That last category of knowledge, the current and the undocumented, is what Unblocked synthesizes from your code, PRs, docs, and conversations and serves to every agent you run. If your rules files keep drifting from reality, try it alongside whichever file you picked.

AI Coding Productivity at Scale: Why the Gains Disappear

Dennis Pilarinos — Thu, 13 Aug 2026 15:00:00 +0000

AI coding gains disappear at scale because they are earned in the one stage of software delivery that was rarely the constraint, and the surrounding system absorbs them before they reach any org-level metric. Your pilot numbers were real. So is the flat dashboard your VP keeps pulling up. The gap between those two facts is the story of AI coding productivity at scale, and DORA's 2026 report on the ROI of AI-assisted software development is blunt about it: AI adoption raises individual effectiveness while also raising delivery instability, and the returns come from the organizational system around the tools rather than from the tools alone. We've already covered the AI productivity paradox, which asks whether individual gains are even real once you measure them properly. This piece assumes they are. The question here is different: where do genuine, keyboard-level speedups go on the way from a developer's editor to lead time, deploy frequency, and roadmap throughput?

Why don't individual AI speedups show up in org metrics?

Because a delivery metric measures a system, and AI accelerates one worker inside it. When one stage of a pipeline speeds up and the stages around it don't, the output of the fast stage piles up as inventory: open PRs, unreviewed diffs, changes waiting on a deploy window. DORA's 2026 ROI report names the mechanisms directly. Reviewing AI-generated code imposes a verification tax. Adoption comes with a productivity dip the report calls the tuition cost of transformation. And rising change-failure rates create an instability tax that can push the net financial impact negative even while individual output climbs. That is what AI coding productivity at scale actually looks like in 2026 telemetry: more code produced per person, roughly the same software delivered per quarter. The pattern holds across vendors whose datasets disagree on almost everything else, which makes it worth explaining rather than explaining away. The rest of this piece walks through the five places the speedup gets absorbed: the review queue, rework, the Amdahl's-law ceiling, coordination cost, and the context-hunting tax every reviewer pays.

Key Takeaways

Individual AI speedups are real at the editor; org dashboards measure the whole delivery system, and the two keep diverging.
Code review is the new constraint: AI-assisted PRs are larger, wait longer for pickup, and merge far less often than manual ones.
Rework refunds part of the speedup as duplicated code, defects, and churn in the sprints that follow.
Coding is a minority share of lead time, so even large coding gains cap out small at the org level.
Measure lead time, rework windows, and review pickup time instead of PR counts or adoption rates.

Where does the speedup actually go?

Into the review queue, first. LinearB's 2026 benchmark study of 8.1 million pull requests across 4,800 teams in 42 countries found that AI-assisted PRs run about two and a half times larger than unassisted ones at the 75th percentile: over 400 changed lines versus 157. Bigger diffs are harder to verify, so they sit. AI-generated PRs wait more than 16 hours for a reviewer to pick them up, over five times longer than the roughly 200 minutes unassisted work waits. Many never land at all: manual PRs merge at about 84.5%, while AI-generated PRs merge at just 32.7%. Faros AI's 2026 "Acceleration Whiplash" report sees the same jam from the other side, with median PR review time up 5x and 31% more PRs merging with no review at all. The queue either clogs or gets bypassed, and both outcomes destroy the org-level gain: a jammed queue converts the speed into wait time, and a bypassed one converts it into risk. Note what didn't change: reviewer intent. Nobody decided to review less carefully; the queue simply outgrew the people staffing it.

The rework refund

Some of the speedup is not absorbed but borrowed. GitClear's 2026 maintainability research found that refactored (moved) code has collapsed to 3.8% of changed lines year-to-date, down from 21% in 2022, while block duplication climbed 81% over 2023 to the highest level on record and error-masking constructs rose 47%. Nobody is paying down the code AI generates; they are stacking more on top, and every duplicated block is a future change that has to be made twice. Defect data completes the loop. Faros AI's telemetry, covering 22,000 developers across 4,000 teams, pairs the individual output gains with the system costs that arrive alongside them:

Metric	Change under heavy AI adoption
Epics completed	+66.2%
Task throughput	+33.7%
Median PR review time	5x
Incidents per PR	3x
Bugs per PR	+28%
Code churn	+861%
PRs merged without review	+31%

Source: Faros AI, AI Engineering Report 2026. The speed you booked this sprint comes back as defect and churn work next sprint. It still shows up on the dashboard, just in the wrong column.

Is coding even the bottleneck? (the Amdahl's-law problem)

Mostly no, and this is the arithmetic that makes the whole pattern predictable. Lead time for changes spans design, coding, review, testing, deployment, and the wait states between them; we've written about how DORA metrics in the AI era capture that full span. If coding is roughly 20 to 30 percent of lead time, Amdahl's law says an infinite coding speedup caps total improvement around 25 to 40 percent, and a realistic speedup on that slice produces single-digit gains at the org level. Those numbers are illustrative rather than measured, but the shape is not, and it caps AI coding productivity at scale hardest in large organizations where wait states dominate: AI accelerates the smallest slice of lead time. A 2026 arXiv analysis of the productivity-reliability paradox makes the same point with telemetry showing 98% more pull requests, 91% longer review times, and flat delivery metrics, concluding that "specification discipline, not model capability, is the binding constraint" on dependable AI-assisted delivery. Pushing more input into a saturated queue raises inventory, not throughput.

What do coordination costs do to team throughput?

They eat a share of it that grows with headcount. Faros AI's core 2026 finding is the whiplash itself: a delivery system built around human-paced code production, suddenly flooded with output it was never designed to absorb. More output per individual means more merge conflicts, a larger integration surface, and more decisions that have to be synchronized across people who are each moving faster alone. Someone absorbs that load. LeadDev's Engineering Leadership Report 2026 found 37% of engineering leaders doing more hands-on technical work than the year before; the leaders became the shock absorbers. Developer-experience surveys keep finding the same wash: the hours AI saves roughly cancel against new hours lost to friction elsewhere in the system. And culture decides how much throughput survives the collision. The Pragmatic Engineer's 2026 survey of 900+ engineers found that teams with strong testing automation and documented decisions convert AI adoption into team gains, while everyone else struggles to. As one staff engineer in that survey put it:

"AI is an amplifier, not a fixer. Good software engineering practices get multiplied. So do the bad ones."

The context-hunting tax, multiplied by headcount

Every AI-generated PR asks its reviewer the same questions. Why is the code shaped this way? Which conventions does it follow or violate? Has this approach been tried and rejected before? The answers live in old PRs, design docs, superseded RFCs, and chat threads, and without a system that surfaces them, every reviewer pays that research cost individually, on every diff, and the diffs are arriving larger and faster than ever. Generated code raises more of these questions because no author remembers writing it. That is the verification tax DORA describes, multiplied by headcount. This is where a context engine changes the aggregation math: giving reviewers and agents the reasoning behind the code compresses verification instead of only accelerating generation. Engineers at UserTesting put the swing at 20 to 30 percent of their productivity, depending on whether institutional context is within reach while they and their agents work. Reclaiming the hours engineers lose to context-hunting is, in aggregate, the difference between a speedup that survives review and one that queues behind it.

Frequently asked questions

Why isn't AI making my team faster?

Because the constraint moved from writing code to reviewing, integrating, and reworking it. Individual speedups queue up at the stages AI didn't touch: LinearB's 2026 data shows AI-assisted PRs waiting over five times longer for review pickup than unassisted ones. Until verification capacity grows to match generation capacity, faster coding mostly produces deeper queues, not shorter lead times.

Do AI coding tools actually improve velocity?

At the individual level, yes. Faros AI's 2026 telemetry shows task throughput up 33.7% and epics completed up 66.2% under heavy adoption. At the org level, lead time and deploy frequency have stayed mostly flat across 2026 measurements. The gap between those two numbers is absorption cost, not measurement error.

Why did our AI pilot results not replicate?

Pilots measure the coding slice under ideal conditions: motivated volunteers working greenfield tasks while the review system has spare capacity. A full rollout saturates review and coordination capacity, which the pilot never tested, on a legacy codebase the pilot never touched. The pilot numbers were real; they measured a stage that stops being the constraint the moment everyone speeds up at once.

Should we measure individual or team-level AI gains?

For AI coding productivity at scale, team-level outcomes are the headline; individual instrumentation is diagnostic. Perception is a poor proxy for either. Jellyfish's 2026 State of Engineering Management survey found that 64% of engineering professionals believe they're getting at least a 25% velocity lift from AI, a belief org-level delivery data rarely confirms at that magnitude. Lead time and rework rates tell you whether the gains actually survived aggregation.

Did the individual gains even survive scrutiny?

Increasingly, yes, and the thesis doesn't need them not to. An earlier randomized trial famously found experienced developers slower with AI even as they believed the opposite; we unpacked that result and the perception gap behind it in the AI productivity paradox. METR's February 2026 update complicates that story in AI's favor: a newer cohort measured a -4% speed effect with a confidence interval spanning -15% to +9%, and the researchers judge it "likely that developers are more sped up from AI tools now" than when the original trial ran, with heavy caveats about selection effects, since developers increasingly declined to participate in trials that would take their AI tools away. Read that as individual gains becoming genuinely real, and probably still understated. It strengthens the argument rather than weakening it, because if keyboard-level speedups are real and org metrics are still flat, the loss is happening in aggregation, exactly where the review, rework, and coordination data says it is.

What to measure next quarter

Three counter-metrics reveal whether your gains survive aggregation, and none of them is PR count. All three are cheap to instrument and hard to argue with. First, lead time for changes, end to end, because it is the number the whole system has to move together. Second, a 14-day rework window on AI-tagged PRs: what fraction of AI-assisted changes get modified or reverted within two weeks of merging. Third, review pickup time split by AI versus human authorship, which is the earliest warning that your queue is jamming. If you can't yet tag AI-assisted PRs, start there, because both of the latter metrics depend on that split. We cover the instrumentation in how to measure AI productivity; for a fuller lens, context-adjusted productivity nets out the verification and coordination costs this piece describes. The 2026 pattern in AI coding productivity at scale is consistent across every dataset above: the teams whose gains survive are the ones that shrank verification. That means putting institutional context where reviewers and agents already work, so the fastest stage of your pipeline stops waiting on the slowest.

Why Claude Code Invents Functions Your Codebase Doesn't Have

Dennis Pilarinos — Wed, 12 Aug 2026 15:00:00 +0000

Claude Code invents functions because it predicts the most plausible API name from patterns in its training data, not from an index of your actual code. You watched it happen this morning. You asked the agent to add rate limiting to password resets, and the diff came back clean: const user = await User.findByEmail(email), wrapped in a sensible guard clause, with a test that mocks the same method. It reads idiomatically. It sails into the PR. Then your reviewer leaves a single comment: findByEmail doesn't exist. Your codebase has getUserByEmail, defined in users/repository.ts and called from fourteen places, and nothing named findByEmail has ever been merged into your repo. The agent didn't misread your code. It never read the relevant file at all, and it filled the gap with the name most other codebases would use.

Why does Claude Code call functions that don't exist in my codebase?

Three causes stack up to produce an invented method call.

First, interpolation. findByEmail is the dominant convention in the Rails, Spring Data, and Mongoose code the model trained on. When Claude Code needs a user-lookup method and your real signature isn't in front of it, it emits the statistically likely name. Engineers on r/ClaudeAI describe this pattern constantly: the agent references files, functions, and code that don't exist anywhere in the project.

Second, partial visibility. Claude Code doesn't hold your repository in memory; it greps and reads files on demand. If it never opened users/repository.ts this session, your actual signature was never in its context window, and prediction is all it has left.

Third, convention drift. Your internal APIs are by definition rare or absent in training data, and fabrication concentrates exactly where the model has seen a name least often. A 2026 re-evaluation of frontier models found five different models inventing 127 identical package names. That is what systematic interpolation looks like: the same wrong answer, reproduced deterministically, by models trained separately.

Bottom line: Claude Code doesn't look up your API before naming it; it predicts a plausible name from ecosystem-wide patterns. The more your internal conventions differ from open-source norms, the more it invents. Rules files reduce the problem, and only grounding the agent in your real signatures and call sites stops it.

How often do coding agents invent APIs?

The cleanest 2026 numbers come from package hallucination, because a package's existence can be checked against a registry. A May 2026 study re-evaluated five frontier models, including Claude Sonnet 4.6 and Claude Haiku 4.5, on 199,845 Python and JavaScript prompts and found that between 4.62% and 6.10% of generations referenced packages that don't exist. Newer models shrank the range, but nobody got near zero, and 127 fabricated names were shared across all five models. The overlap matters more than the rate: the failure comes from how these models generalize, and no single vendor is going to patch it away.

Developers feel this. Stack Overflow's February 2026 analysis of its survey data shows adoption and confidence moving in opposite directions: over 84% of developers use or plan to use AI tools, while only 29% say they trust AI, down 11 points year over year.

Internal-API invention is the same mechanism pointed at your codebase, with one difference. When a model invents a package, npm install fails loudly. When it invents findByEmail, nothing fails until the type checker, the reviewer, or production.

What does an invented function look like in the wild?

Reports of Claude Code hallucinations converge on the same shape: confident code, plausible name, missing referent. In January 2026, a developer documented Claude generating file-upload code around a Prisma method called $upload. The generated code was confident and tidy; the runtime verdict was TypeError: prisma.$upload is not a function. Prisma has no $upload method. The model invented it whole.

Claude Code's own issue tracker shows the family of failures: users report the agent pausing long-running tasks over hallucinated missing dependencies and making unverified assumptions instead of checking actual state.

Then there's the security tail. Invented names are so consistent that attackers pre-register them. In January 2026, Aikido Security claimed the npm name react-codeshift, a package that never existed but that 237 GitHub repositories were already instructing agents to install. By July, researchers demonstrated "HalluSquatting" attacks that plant malware behind reliably fabricated repository names, with success rates up to 85%. If invention were random noise, none of this would work.

Does CLAUDE.md stop Claude Code from making up methods?

Partially, and it's worth doing. CLAUDE.md files give the agent persistent instructions loaded at session start, so conventions you write down ("user lookups live in users/repository.ts; never invent repository methods") survive across conversations.

What they can't do is close the gap. A mid-size repo has thousands of exported symbols, and the set changes with every merged PR, so any rules file that enumerates your API surface is stale by Friday. Nobody maintains a hand-written index of their own code, and CLAUDE.md quietly asks you to. Rules are instructions, not retrieval: when the real signature isn't in context, the model still produces method names by prediction, and Anthropic's own docs are explicit that CLAUDE.md content is context the model tries to follow rather than enforced configuration. Long rules files also pay a context tax every session; the same docs recommend keeping them under 200 lines, which rules out documenting your API there. None of this is CLAUDE.md's fault: Claude Code doesn't retain your codebase shape between sessions, so instructions end up doing a job that only retrieval infrastructure can do.

Can you just paste more of the repo into the context window?

This is the other folk remedy, and it helps less than it looks like it should.

Scope: pasting users/repository.ts grounds the agent in exactly that file, for exactly this session. The next invented call will come from a module you didn't paste, and tomorrow's session starts from zero.

Attention: a repo stuffed into the window still gets skimmed, and a signature the model glossed over might as well not be there. Bigger windows raise the ceiling without changing the behavior, because attending to a million tokens is not the same as looking one symbol up.

Staleness: the repo mutates under you. Yesterday's paste contains yesterday's signatures, and an agent grounded in last week's snapshot will confidently write calls against methods your team renamed on Tuesday. Cursor has its own version of this failure, where the same context limits show up as forgetting rather than inventing. Same underlying gap: the agent has a sliver of your code when it needs an index of it.

What actually grounds an agent in the code you have?

Retrieval of what actually exists, at the moment the agent is about to write the call: the real signature, the real call sites, and the convention your team settled on. 2026 research converges here. A January 2026 framework parses generated code and validates every reference against a knowledge base built from the actual libraries in use, catching non-existent APIs with 100% precision and 87.6% recall, and auto-correcting 77% of them. The principle generalizes: check generation against ground truth instead of hoping prediction lands.

That's the job Unblocked does for coding agents: it grounds them in what actually exists. It's the context engine coding agents query before they write, and it surfaces real signatures, call sites, and team conventions at the moment of need, along with the decisions behind them from PRs, docs, and chat. When the agent asks what the user-lookup method is called, it gets back getUserByEmail, the file it lives in, and the discussion where the team standardized on it, instead of a statistically popular guess.

My setup tells the agent: before you implement anything, go check Unblocked. It has everything — our repos, Notion, Slack, coding standards — and it surfaces things I wouldn't have thought to look for. GitHub Copilot doesn't have any of that organizational context. I'd rate the impact an eight or nine out of ten, and it's only gotten better.

— Justin McCraw, Software Engineer, The Information

Grounding also raises the question of precedence when sources disagree, which is its own problem: which source of truth should the agent trust.

Making the inventions stop

Three concrete moves, in order of cheapness:

Make "does this symbol exist?" a hard gate. A grep or a typecheck in the loop, before the diff lands, catches most invented calls for pennies. If your language has a compiler, run it; if it doesn't, a symbol-existence check in CI is the next best thing.
Audit your CLAUDE.md for retrieval problems wearing rule costumes. Every line shaped like "use getUserByEmail, not findByEmail" is a patch over a lookup the agent should be doing itself. Keep the conventions; stop trying to enumerate the API surface.
Give the agent a query path to what exists. Signatures, call sites, decisions. An agent that can ask before it writes has no reason to guess, and an agent that can only predict will keep predicting.

The inventions are what generation without grounding looks like, and the next model release won't fix that.

Frequently asked questions

Why does Claude Code make up functions?

Because it generates the most plausible method name from patterns in its training data rather than looking up your actual API. When the real signature isn't in its context window, ecosystem-wide conventions fill the gap, which is why the invented names (like findByEmail) sound so reasonable.

How do I stop my coding agent inventing methods?

Put a symbol-existence check (typecheck, grep, or compile) in the loop before any diff lands, and give the agent retrieval access to your real signatures and call sites so it queries instead of guessing. Rules files help at the margins but don't do retrieval.

Does CLAUDE.md stop hallucinations?

It reduces them for the conventions you thought to write down. It can't cover thousands of exported symbols that change every PR, and instructions don't substitute for retrieval: the model still predicts names when the real one isn't in context.

Is calling a deprecated API the same as inventing one?

No. A deprecated API is old but real: it existed, and the agent's knowledge is out of date. An invented API never existed anywhere. One is a freshness problem, the other a grounding problem, and they need different fixes.

Does this happen more in big codebases and monorepos?

Yes. Large codebases carry more internal conventions that diverge from open-source norms, and less of their API surface resembles anything in training data. More symbols, more drift, more room for a plausible-but-wrong name. Which is also where symbol checks and grounded retrieval pay off most.

8 Best Glean Alternatives for Engineering Teams (2026)

Dennis Pilarinos — Tue, 11 Aug 2026 16:29:53 +0000

Originally published at getunblocked.com on August 11, 2026.

Unblocked is the top Glean alternative for engineering teams in 2026, and the clearest evidence is what it removes from the calendar: at Fingerprint, VP of Engineering Ekan Subramanian reports his team saves 60 to 70 hours every week on internal Q&A. Some honesty before the list, though. If what you actually need is generic company-wide enterprise search across HR policies, sales decks, and legal contracts, several of the tools below fit that job better than Unblocked does. Unblocked is the pick when engineering is the team that hurts. Most searches for Glean alternatives start with sticker shock at custom quotes and seat minimums, then land on a second complaint: generic answers to engineering questions. This roundup covers 8 alternatives with real 2026 pricing and honest fit guidance for both situations.

Key Takeaways

Unblocked is the top pick when engineering knowledge is the problem; Fingerprint reports 60 to 70 hours saved per week on internal Q&A.
Onyx is the best open-source option: MIT-licensed, self-hostable, with a free community edition.
Atlassian Rovo is the default if you already pay for Jira and Confluence; Notion AI wins if your company runs on Notion.
Dashworks is the budget pick, with published pricing from $10 per seat per month.
The deciding question is whether your pain is company-wide document search or engineering context scattered across code, PRs, and Slack.

How do the top Glean alternatives compare on pricing?

Glean does not publish list pricing. Buyer-reported data from Vendr puts the median Glean contract at $98,890 per year across 174 recorded purchases, with minimum commitments that often start around 100 to 250 users. That opacity is a big part of why teams comparison-shop in the first place, so here is the whole field in one table. Every figure below was re-verified against the live vendor pricing page in August 2026.

Tool	Starting Price	Free Tier	Contract Minimum
Unblocked	$19-$29/user/mo (annual, by plan)	21-day free trial	None stated
Guru	Custom / contact sales	Not published	Custom
Atlassian Rovo	Included with paid Jira/Confluence plans; Rovo Dev $20/dev/mo	Rovo credits included in paid plans	Requires a Jira or Confluence subscription
Notion AI	Included in Business plan at $20/member/mo	Limited AI trial on free plan	None
Dashworks	$10/seat/mo (annual)	14-day free trial	None on Team; 10 seats on Business
Onyx	Free self-hosted; Cloud $20/user/mo (annual)	Yes, open source	None
Microsoft 365 Copilot	$30/user/mo (annual)	No	Requires a Microsoft 365 subscription
Google Gemini Enterprise	$21/seat/mo (Business edition)	30-day trial	Business edition capped at 500 users; larger deployments custom
Glean (reference)	Custom / contact sales	No	100-250 users reported

Why are engineering teams looking for Glean alternatives in 2026?

Cost is the trigger that starts most comparisons of Glean competitors. A six-figure median contract and triple-digit seat minimums are hard to justify when only one department is in pain. But the complaint that sustains the search is answer quality on engineering questions.

Enterprise search tools rank documents. Engineering questions rarely live in one document. "Why does the billing service retry three times?" has its answer spread across a PR review thread, a Slack argument, and a config change from 2023. Sonar's State of Code developer survey found developers spend nearly a quarter of their work week on toil like debugging poorly documented legacy code. The same survey names finding information and understanding existing systems among the toil tasks that most hinder productivity. A search box that returns ten links does not reclaim that time; the difference between ranking documents and reasoning over them is the core of the context engine versus enterprise search distinction.

What should you look for in a Glean alternative?

Six criteria separate the field:

Source coverage: does it read code, PRs, and review threads as first-class sources, or only docs and wikis?
Answer quality: does it synthesize an answer with citations, or return a ranked list of links?
Permissions: does it enforce the source system's access controls automatically?
Deployment speed: days or quarters?
Pricing transparency: published numbers or a sales call?
Scope: engineering-specific depth or company-wide breadth?

That last criterion is where this market actually forks. If legal, HR, and sales all need search, shortlist the generic tools: Copilot, Gemini Enterprise, Dashworks. If the expensive questions come from engineers, you want a context engine, which is a different category than search, not a nicer version of it.

What are the best Glean alternatives for engineering teams?

1. Unblocked: best for engineering teams

Unblocked is a context engine for engineering teams, not a company-wide search box. It connects code, pull requests, Slack, Jira, Notion, and Confluence, then reasons across them to answer the questions search can't: why a system works the way it does, what was tried before, who decided. Answers are grounded in code, PRs, and the discussions around them rather than in documents alone, which is why it can serve as institutional memory for teams whose real knowledge never made it into a wiki. The same context layer also powers its AI code review, so the tool that answers your questions is grounded in the same history that reviews your pull requests.

Unblocked brings everything together. You don't have to go digging through tools. It just works.

— Wade Bruce, CTO, Fetch

The proof points are concrete: Fingerprint's 60 to 70 hours per week saved on Q&A, and pricing published at $19 to $29 per user per month depending on plan, with a 21-day free trial and no stated seat minimum.

The honest limit: Unblocked is deliberately not trying to index your HR handbook. If you need one tool for legal, sales, and engineering content, a generic option below fits better. For the direct feature-by-feature matchup, see the full Unblocked vs Glean comparison, or the three-way comparison with Augment if coding assistants are also on your list.

2. Guru: best for verified company wikis

Guru is a wiki and search hybrid whose distinctive feature is verification: subject-matter experts get prompted on a schedule to re-confirm that cards are still accurate, so answers carry a "verified" stamp with a name attached. For teams whose problem is stale, contradictory documentation, that workflow is genuinely useful, and Guru's AI answers inherit the trust of the verified content underneath.

The tradeoff is source depth on the engineering side. Guru reads knowledge that people wrote down; it is weaker on code, pull requests, and the discussion threads where engineering decisions actually happen. Pricing has also moved away from self-serve: Guru no longer publishes tiered pricing and instead scopes each contract through a sales consultation, which puts it in the same opaque bucket as Glean on the transparency criterion.

3. Atlassian Rovo: best if you already live in Jira and Confluence

Rovo is Atlassian's AI search and agent layer, and its pitch is that you may already own it: Rovo is included with Standard, Premium, and Enterprise cloud plans for Jira and Confluence, with usage metered in Rovo credits instead of a separate per-seat fee. Rovo Dev, the developer-focused agent, is priced separately at $20 per developer per month with 2,000 credits included.

If your team's knowledge already lives in Atlassian's ecosystem, that bundling makes Rovo the cheapest experiment on this list. The limit is the flip side: Rovo is strongest inside Atlassian's own graph. Connectors reach outward, but teams whose critical context lives in Slack threads and GitHub review comments will find the answers thinner there, and you cannot buy Rovo without the underlying Atlassian subscription.

4. Notion AI: best for Notion-centric teams

Notion AI answers questions across your Notion workspace and connected apps, and its economics are simple: AI is included in the Business plan at $20 per member per month, with a limited trial on the free plan. For companies that already run their docs, projects, and meeting notes in Notion, that means enterprise Q&A arrives as a plan upgrade rather than a new procurement cycle.

The boundary is Notion's orbit. Knowledge inside the workspace is well served; knowledge outside it, especially code and pull requests, is second-class. Notion AI can search some connected tools, but it does not reason over a repository's history or a review thread's back-and-forth. Treat it as the answer layer for the company wiki rather than for the engineering org's tribal knowledge.

5. Dashworks: best budget AI search assistant

Dashworks is a Slack-first AI search assistant with the most approachable pricing on this list: the Team plan runs $10 per seat per month billed annually ($12 monthly), with a 14-day free trial, no credit card, and no seat minimum. The Business tier adds custom bots and org-wide integrations at $12 per seat annually with a 10-seat minimum. Setup is fast because it works where your team already asks questions.

What you give up is depth. Dashworks federates search across connected apps and drafts answers from what it finds, which works well for support-style questions with a documented answer. It is lighter on reasoning over engineering artifacts, so "why" questions that span a PR, a Slack thread, and a config change will stretch it. As a low-risk pilot for general-purpose AI search, it is the easiest start here.

6. Onyx: best open-source alternative

Onyx (formerly Danswer) is the self-hosting route: the community edition is MIT-licensed and free with more than 50 connectors out of the box, and the managed cloud offering runs $20 per user per month billed annually. For organizations where data residency or air-gapped deployment is non-negotiable, it is the only credible option on this list, since everything can run inside your own VPC.

The cost shows up in operations instead of licensing. You own the upgrades, the index, the model configuration, and the connector maintenance, and that adds up to a real engineering commitment. Answer quality also depends heavily on how well you tune it. Choose Onyx when control is the requirement; choose a managed tool when speed matters more.

7. Microsoft 365 Copilot: best for Microsoft-first enterprises

Microsoft 365 Copilot costs $30 per user per month billed annually, on top of a qualifying Microsoft 365 subscription. What you get is permission-aware search and chat across the Microsoft Graph: SharePoint, Teams, Outlook, OneDrive, and the Office apps themselves. For an enterprise standardized on Microsoft, that is a huge surface area with governance already handled, and procurement is an add-on to a contract you already have.

Coverage thins quickly outside that graph. Connectors exist for third-party sources, but the experience is built around Microsoft's own estate, and engineering systems like GitHub (despite shared ownership), Jira, and Slack sit outside the default value. If your knowledge lives in Office documents and Teams messages, Copilot is the obvious pick; if it lives in repos and review threads, it is a complement rather than an answer.

8. Google Gemini Enterprise: best for Google Cloud shops

Gemini Enterprise is Google's entry, launched in late 2025 as the successor to Agentspace. Pricing is published: the Business edition starts at $21 per seat per month for teams of up to 500 users with a 30-day trial, and Standard and Plus editions start at $30 per seat through sales. The agent platform underneath adds usage-based billing for compute and storage, so total cost scales with how heavily you build on it.

The fit is Google-shaped: Workspace content, BigQuery, and Google Cloud services are first-class, and the agent-building tooling is further along than most rivals'. The caution is maturity. The platform has been renamed and rebundled within the last year, larger contracts remain custom-quoted, and the usage-based components make budgeting less predictable than a flat per-seat tool.

How do you choose between them?

Match the tool to your situation instead of the feature grid:

Engineering knowledge is the pain: Unblocked.
You already pay Atlassian: try Rovo first, since the credits are bundled.
Company runs on Notion: Notion AI is one plan upgrade away.
Self-hosting is mandatory: Onyx, and budget the ops time honestly.
Microsoft or Google estate: Copilot or Gemini Enterprise respectively.
Small budget, general-purpose need: Dashworks.
Documentation trust is the real problem: Guru.

Price the shortlist with the table above, remembering that the bundled options (Rovo, Notion AI, Copilot) are only cheap if you already pay for the platform underneath. If several tools tie, source coverage should break the tie; our roundup of AI tools for engineering teams goes deeper on evaluating that.

Frequently asked questions

What is the best Glean alternative for engineering teams?

Unblocked. It reasons across code, PRs, Slack, Jira, Notion, and Confluence rather than ranking documents, and customers report large concrete savings: Fingerprint's VP of Engineering cites 60 to 70 hours per week recovered from internal Q&A. For a feature-level breakdown, read the Unblocked vs Glean comparison.

Is there a free or open-source alternative to Glean?

Yes. Onyx is MIT-licensed and free to self-host, with a managed cloud tier at $20 per user per month. If you already pay for Jira or Confluence, Atlassian Rovo is effectively free to try since credits are bundled with paid plans. Notion's free plan includes a limited Notion AI trial.

How much does Glean cost compared to alternatives?

Glean is custom-quote only. Vendr's buyer data shows a median contract of $98,890 per year, with minimums often reported between 100 and 250 users. The alternatives here publish prices from $10 to $30 per user per month, and several (Rovo, Notion AI) are bundled into subscriptions you may already carry.

What is the difference between enterprise search and a context engine?

Enterprise search indexes documents and ranks them against your query; a context engine connects code, PRs, and conversations, then reasons across them to produce an answer with sources. Search tells you where information might be; a context engine tells you why things are the way they are. The full comparison walks through the architecture behind that difference.

Shortlisting for your evaluation

A practical shortlist has three tools on it: one engineering-specific option (Unblocked), one from the ecosystem you already pay for (Rovo, Copilot, Notion AI, or Gemini Enterprise), and one wildcard (Onyx if self-hosting matters, Dashworks if budget does). Then run the same test on all three: pull the last ten real questions from your team's Slack history, ask each trial verbatim, and score the answers against what a senior engineer would say. That test is hard to game, and it is where the gap between ranking documents and reasoning over engineering context shows up. If engineering is the team that hurts, start a free trial of Unblocked and run those ten questions against your own repos and Slack first.

What Is Context Rot? Why AI Agents Degrade Mid-Session

Dennis Pilarinos — Tue, 11 Aug 2026 16:29:20 +0000

Originally published at getunblocked.com on August 10, 2026.

Context rot is the gradual degradation of an LLM's output quality as its context grows — the model starts missing, misreading, or ignoring information that is still right there in the window. It sets in long before the window is full, and it is the usual reason an agent that felt sharp for the first hour starts fumbling in the second. Nothing broke, and no data was lost. The model is simply using its own context worse than it did at the start of the session.

TL;DR: An LLM's output quality decays as its context window fills, even though the information it needs is still present in the window. The cause is a finite attention budget, not finite memory: every token in the window competes for the model's attention. The fix is to curate what enters the context instead of enlarging the window.

What is context rot?

Context rot is the decline in a model's ability to accurately use information already sitting in its context window as the token count grows. Instructions get dropped and recall turns fuzzy even though every relevant token remains technically available to the model.

The term came out of long-context recall research and has since become standard engineering vocabulary; Anthropic's own model documentation now defines it by name. It is distinct from hallucination, which is fabrication and can happen at any context length, and from model staleness, which is about training data ending at a cutoff date. Rot is specific to what happens inside a single growing session.

It matters because degraded output has a human price. In Sonar's 2026 State of Code survey of more than 1,100 developers, 96% said they do not fully trust AI-generated code, and only 48% always verify it before committing. A rotting session produces exactly the kind of output that deepens that verification burden.

Why does context rot happen?

Attention is a budget. A transformer relates every token in the window to every other token, and the attention any single fact receives shrinks as the pool grows. Anthropic's context window documentation is blunt about the consequence: more context is not automatically better, because accuracy and recall degrade as token count climbs. The window is working memory, and working memory gets crowded.

Position matters too. Models are trained mostly on shorter sequences, so they weight the beginning and end of the window more reliably than the middle. Material buried mid-window, like the design decision from forty minutes ago or the constraint stated once inside a long file dump, is the first to fade. OpenAI's prompt engineering guidance likewise recommends keeping the content you reuse across requests at the beginning of the prompt.

Then there is noise. A long agent session accumulates stale tool output and abandoned approaches, all of it competing for attention with the tokens that actually matter.

What does it look like in an agent session?

The symptoms are easy to recognize once you map them to their causes:

Forgotten instructions. Rules from your instruction file stop being applied mid-session. That is mid-window loss: the rules are still present, but attention has moved elsewhere.
Contradicted decisions. The agent agreed to an approach an hour ago and now argues for the opposite, because the original discussion has faded.
Repeated work. It re-reads files or re-runs checks it already completed, a sign its recall of session history has degraded.
Confident misquotes. It describes a function or config it read earlier and gets the contents wrong while sounding certain.
Trial-and-error drift. Precise, reasoned edits give way to guess-and-check loops as reasoning quality drops.

Bloated instruction files accelerate all of this, because every preloaded rule spends attention budget before real work begins. And the burden lands on people: The Register's coverage of the Sonar survey notes that 95% of developers spend at least some effort reviewing AI output, and 59% rate that effort moderate or substantial.

Frequently asked questions

Why does my agent get worse the longer it runs?

Because every turn adds tokens, in the form of tool output, diffs, and logs, and every added token dilutes the attention available to everything else. Small per-step errors then stack rather than average out, which is why 2026 work toward a science of AI agent reliability proposes measuring agents on consistency and robustness across runs alongside single-attempt success. Session length itself is the risk factor.

Does a bigger context window fix it?

No. A larger window raises the ceiling on how much you can load, but degradation begins well before any advertised limit, so extra capacity mostly gives the decay more room to operate. The fuller answer is in the next section.

Is context rot the same as hallucination?

No. Hallucination is fabrication: the model invents information it never had, and it can occur in a ten-line prompt. Rot degrades the model's handling of information it does have, and it worsens with length. They do interact: a rotted session hallucinates more, because weak recall gets papered over with plausible invention.

Can you fix it by restarting the session?

Partly. A fresh session drops the accumulated noise, but it also drops legitimate context, including the decisions and constraints you established along the way. Teams square this with retrieval on demand, using a context engine such as Unblocked to pull the relevant history back in when it is needed instead of hoping the window still holds it.

Does a bigger context window fix context rot?

Advertised windows keep growing; Anthropic's current models accept up to a million tokens. Effective context has not kept pace. Output quality degrades well before the advertised limit, which is why practitioners treat effective context as a fraction of the number on the spec sheet rather than the number itself.

For agents, the problem compounds. Suppose degradation drags an agent from near-perfect down to 85% reliability on each individual step. Run ten dependent steps and the chance of a clean end-to-end run is 0.85 to the tenth power, roughly 20%. That is only arithmetic, but it explains why long sessions fail in slow motion. It is also why 2026 evaluation research argues that single-attempt benchmarks hide how agents decay across long horizons.

A bigger window lets you load more, and that is all it does. What fits in the window and what the model can actually use are different questions.

Is context rot the same as running out of context?

No, and glossaries routinely blur the two. Running out of context is overflow: the session hits the window's hard limit and something visible happens, such as truncation, a compaction pass, or an error. Rot is quieter. It happens mid-window, with room to spare and every token still present; the model just uses them worse.

Context overflow	Context rot
Session hits the hard token limit	Window still has room to spare
Old content is truncated or summarized away	All content is still present in the window
Announces itself with warnings or errors	Silent; visible only as declining quality
Managed by trimming or splitting sessions	Managed by curating what enters at all

The distinction changes the remedy. Overflow is a capacity problem you can schedule around. Rot is a quality problem that starts the moment the window begins filling, which is why the fixes below focus on curation rather than compression.

Where does it hit hardest?

Long-horizon coding agents, by a wide margin. An agentic loop stacks tool output on tool output: file reads, diffs, test logs, shell results. Most of it is single-use noise the moment the step completes, yet all of it stays in the window. Sessions that run for hours accumulate exactly the conditions rot needs.

Tooling overhead makes it worse. Connect a handful of MCP servers and their schemas can consume a meaningful slice of the window before the first real task token arrives. The budget gets spent on plumbing.

This tracks the broader reliability picture: the International AI Safety Report 2026 treats the dependable behavior of general-purpose AI systems as an open scientific problem. If you run Claude Code, we have a field guide to context rot in Claude Code specifically, including where in a session it tends to bite.

How do teams prevent it?

Four categories of mitigation hold up across tools:

Curate what enters. Prune instruction files down to the rules the agent actually violates without them. Trim tool inventories and schemas. Treat every preloaded token as attention already spent.

Reset at phase boundaries. Finish planning, then start implementation in a fresh session that carries forward a short summary instead of the full transcript. You keep the conclusions and shed the noise.

Isolate side tasks. Send research and exploratory work to a separate session or subagent so its intermediate output never pollutes the main thread. Only the distilled answer comes back.

Retrieve on demand. Instead of preloading everything an agent might need, fetch what it needs at the moment it needs it. This is where a context engine fits: Unblocked, the context engine for engineering, resolves the relevant PR thread, doc, or past decision when the question comes up, so the window carries answers rather than archives.

Getting agents to manage this budget themselves is an active research area; Self-GC, from 2026, has agents governing their own context on long-horizon tasks.

How to spot it in your own sessions

Run a quick three-item self-check on any session that has been running for a while:

The agent re-asks questions you already answered.
It contradicts a decision the two of you settled earlier.
Output quality falls off a cliff right after a long stretch of tool output or file dumps.

Any one of these means the window is working against you, and the answer is rarely a bigger model or a bigger window. Rot is a curation problem, not a capacity problem: sessions stay sharp when the context contains what the current step needs and little else. That discipline can be manual, or it can come from tooling that retrieves context on demand, which is the job we built Unblocked to do.

Why Does Your Coding Agent Keep Using Deprecated APIs? (And How to Stop It)

Dennis Pilarinos — Tue, 11 Aug 2026 16:29:00 +0000

Originally published at getunblocked.com on August 7, 2026.

Your coding agent keeps using deprecated APIs for two reasons, and neither one is fixable with a sterner prompt. First, its training data is frozen in the past: every model ships with a knowledge cutoff, so a deprecation your team announced in March simply doesn't exist in the model's head. Second, its retrieval can't tell current from stale. Your codebase still contains the old pattern in a hundred call sites, your wiki still documents it, and an example file from 2023 still demonstrates it beautifully. The agent takes the first plausible match, and the first plausible match is usually the old one, because old code outnumbers new code in almost every repository on earth.

The short version: your agent isn't stubborn, it's outdated by construction. Its training predates your deprecation, and nothing in its retrieval ranks a three-year-old example file below last month's migration PR. Until something ranks sources of truth by recency and authority, it will keep reaching for the pattern it has seen most often.

Why do agents reach for deprecated code at all?

Because the old API dominates everything the model has ever seen. Anthropic publishes a training data cutoff for every Claude model, and even distinguishes it from a "reliable knowledge cutoff," the date through which knowledge is most trustworthy (Anthropic model docs). OpenAI does the same for GPT models (OpenAI model docs). Anything deprecated after those dates is invisible to the weights, and the gap is bigger than it looks: a model released this summer can be confidently wrong about a library that changed before you finished reading its launch post.

Frequency makes it worse. An API that lived for five years has five years of tutorials, Stack Overflow answers, and blog posts behind it; its replacement has a few months. Stack Overflow's own analysis of the developer AI trust gap lists "methods that were deprecated years ago" among the most common failure modes developers report, alongside APIs that never existed at all (Stack Overflow, 2026). When the model emits deprecated code, it's doing exactly what its training distribution taught it to do.

How does an agent decide which API version to trust?

It doesn't decide. It satisfices. When your agent needs to call your billing service, it searches, finds something that compiles, and moves on. The wiki says one thing, the code says another, and an old example file says a third, and nothing in the loop ranks those against each other. This is satisfaction of search in action: the agent stops at the first plausible answer, not the best one. Ask for a new webhook handler and it models it on whichever existing handler it found first. If that's deprecated code, you now have one more copy of it.

That's why the same prompt on the same model produces different code depending on which files happen to land in context. The deprecation decision exists, but it lives in a Slack thread and a merged PR, exactly where your coding agent can't see.

Why doesn't a bigger context window solve it?

Stuffing everything into a million-token window makes the ranking problem worse, not better. Anthropic's own docs are blunt about it: more context isn't automatically better, because accuracy and recall degrade as token count grows, a phenomenon they name context rot (Anthropic context docs). We've written about how that plays out in practice in Claude Code sessions.

The independent numbers back this up. Zylos Research's 2026 survey of long-context evaluation found models typically become unreliable 30-40% before their claimed context limit, and attributes nearly 65% of 2025 enterprise AI failures to context drift or memory loss during multi-step reasoning (Zylos, 2026). If you paste the old docs, the new docs, and the migration guide into one giant prompt, you haven't told the agent which one wins. You've just given it more plausible matches to satisfice against. The window is working memory, not a source of truth, and something upstream still has to decide what deserves the space.

What does shipping deprecated code actually cost?

It compounds. GitClear's 2026 analysis of 623 million code changes found duplicated blocks up 81% since 2023, while moved code, its proxy for refactoring, fell to 3.8% of changed lines (GitClear, 2026). Every time an agent copies a deprecated pattern into a new file, it adds one more stale call site for the next agent to find and imitate. Multiply that across a team where agents write a growing share of commits, and deprecated APIs stop being a cleanup chore and become load-bearing. Sonar's Tom Howlett describes the same dynamic: agents add code but rarely delete it, so superseded functions accumulate next to their replacements (InfoWorld, 2026).

Note what this isn't: a capability problem. Stanford's 2026 AI Index reports SWE-bench Verified performance rose from 60% to near 100% in a single year (Stanford HAI, 2026). The models can write the code. They just can't tell which API you actually want written.

Do rules files and deprecation comments fix this?

Partially, and honestly, that's worth having. A line in CLAUDE.md saying "use PaymentClientV2, never PaymentClient" works the day you write it. @deprecated annotations help too, when the agent reads the annotated file. But three limits show up fast. First, rules files rot: nothing breaks when a rule goes stale, so the drift stays invisible until an agent acts on it. Second, they don't scale. Keeping CLAUDE.md, AGENTS.md, and .cursorrules in sync is hard in one repo and hopeless across fifty. Third, nobody updates them, because the deprecation decision happened in a PR review or a Slack thread, and writing it into a rules file is unrewarded manual work.

That's the honest assessment behind the rules files vs. context engine tradeoff. Qodo's survey of 609 developers found 65% say AI misses relevant context during critical tasks (InfoWorld, 2026). A hand-edited file was never going to close that gap alone.

What actually works: ranking sources of truth

The fix is a context layer that knows recency and authority, so the agent stops treating a 2023 example file and last month's migration PR as equal witnesses. This is what Unblocked does: it synthesizes your PRs, Slack decisions, and migration history into decision-grade context, so instead of three conflicting matches, the agent sees "this API was deprecated in March, use X instead," with the reasoning attached. It's institutional memory your agents can query instead of a file someone has to remember to edit.

Here's how one team wires it in:

The first instruction in every agent project file is: before making any changes, gather context. That pulls from Jira, Confluence, and Slack via Unblocked — because that's where most of our knowledge actually lives, in threaded discussions. I set it up the day it was announced and now I don't even think about it. I just get the relevant information.

— Andrei Antanovich, Software Engineer, Waste Logics

Unblocked doesn't generate code. It's the context engine that feeds your agents, whichever agent you run, the current answer instead of the most common one.

Frequently asked questions

Why does my agent repeat the mistake even after I correct it?

Your correction lives in one session's context, and it evaporates when the session ends. The model's weights still favor the old pattern, and the stale sources that misled it are all still there. Unless the correction lands somewhere durable that gets retrieved next time, every fresh session starts from the same frozen prior. That's why teams that fix this fix it at the retrieval layer, not the prompt.

Will a newer model stop suggesting deprecated APIs?

It moves the cutoff, not the problem. A newer model knows about public deprecations up to its training date, but your internal deprecations never appear in any training set. The day after release, the model is frozen again while your codebase keeps moving. Retrieval that ranks freshness is what closes the gap, not the release calendar.

Should I delete old code so agents can't find it?

Deleting genuinely dead examples and stale wiki pages helps a lot; they're pure noise. But you can't delete a deprecated API mid-migration while callers still exist. That's exactly when agents do the most damage, and when a context layer that flags "deprecated, migration in progress, use X" earns its keep.

The 20-minute version to try this week

Pick the one deprecation your agents trip over most, and run this: grep the old call sites and check what an agent doing "search, then imitate" would find. Read where the current guidance actually lives; if it's a Slack thread and a merged PR, no rules file mentions it, which means no agent can honor it. Then do two cheap things: delete or quarantine the stalest example file, and add one line to your rules file naming the replacement. That buys you weeks. For the durable fix, make context-gathering the first step of every agent session, the way Andrei's team does, with a context layer that ranks your sources of truth by recency and authority. Your agent was never confused about how to write code. It was confused about which of your five answers was current, and that's a problem you can now actually solve.