Why Faster AI Coding Assistants Haven't Made Your Team Faster

AI coding assistants save time on the part of software delivery that was already fast: producing a plausible draft. They do not save time on the part that was slow, which is knowing what your organization has already decided, who owns what, and which constraints apply to this change. When an assistant lacks that context, the minutes it saves in the editor come back as review comments, rework, and senior engineers explaining the same history again.

That is the short answer to a question many engineering leaders are asking this year. Your developers have an assistant in the IDE, another in the terminal, and a review bot on pull requests, and the calendar looks the same. Nothing is wrong with the models. The tools are each working from a small slice of what your company knows.

This article explains where the time goes, gives you a four-layer audit you can run with any toolset, and shows what changes when every assistant and every reviewer reads the same organizational memory.

The Productivity Numbers Don't Match the Demo

The adoption story is settled. In the 2025 Stack Overflow Developer Survey, 84% of respondents said they use or plan to use AI tools in their development process ^[1]. The sentiment story is moving the other way: favorable views of AI tools fell from above 70% in 2023 and 2024 to 60% in 2025 ^[1].

The reason developers give is specific. Sixty-six percent named "AI solutions that are almost right, but not quite" as a frustration, and 45.2% said debugging AI-generated code takes more time ^[1]. More developers distrust the accuracy of AI output (46%) than trust it (33%) ^[1].

Controlled measurement is harder to come by, and the best-known result needs its date attached. In early 2025, METR ran a randomized controlled trial with 16 experienced open-source developers working 246 real issues in repositories they had contributed to for years ^[2]. With the AI tools of that period allowed, tasks took 19% longer, while the same developers forecast a 24% speedup and afterward still believed AI had made them about 20% faster ^[2].

That number is a snapshot of early-2025 tools, not a description of today. In a February 2026 follow-up, METR wrote that developers are likely more sped up by AI tools now than its early-2025 estimate suggested, and its new estimates lean toward a speedup with confidence intervals that still include zero ^[8]. It also explained why it cannot say how large the change is: 30% to 50% of developers said they were choosing not to submit some tasks because they did not want to do them without AI, so METR describes its new data as only very weak evidence for the size of the increase ^[8].

Two findings from that research hold up for your planning whichever way the headline number moves. Developers misjudged their own speed by a wide margin, so self-reported productivity is not a measurement ^[2]. And one contributing factor the authors discuss is implicit requirements around documentation, testing, and formatting that take humans substantial time to learn ^[2].

Individual speed is also not team speed. That is the gap DORA's research points at later in this article, and it is where missing context does its damage.

Those implicit requirements are the subject of the rest of this article. An experienced maintainer carries them in their head. The assistant does not have them at all.

"Almost Right" Is a Context Problem

Here is what "almost right" looks like in practice. A developer asks an assistant to add a client for the billing service. The assistant produces this, and it passes lint, types, and the unit tests it wrote for itself:

# Generated: works in isolation, wrong for this organization
import time
import requests

def fetch_invoice(invoice_id: str) -> dict:
    for attempt in range(5):
        resp = requests.get(f"https://billing.internal/v2/invoices/{invoice_id}")
        if resp.status_code == 200:
            return resp.json()
        time.sleep(2 ** attempt)
    raise RuntimeError("billing unavailable")

Nothing in the diff is a bug. Three things are wrong anyway, and none of them is visible from inside this repository. The platform team decided last quarter that all internal HTTP calls go through a shared client that handles retries, tracing, and service authentication. The billing API's v2 route is scheduled for removal, a fact recorded in another team's repository. And hand-rolled retry loops were the cause of a retry storm during an incident, which is why the shared client exists.

The version a well-informed engineer would write is shorter:

# Aligned with the platform decision: shared client, current API version
from commons.http import service_client

billing = service_client("billing", api_version="v3")

def fetch_invoice(invoice_id: str) -> dict:
    return billing.get(f"/invoices/{invoice_id}").json()

The difference between the two is not model quality. It is access to three facts: a decision, a cross-repository dependency, and the reason behind a constraint. When the assistant lacks them, a reviewer has to supply them in the review thread, which is slower than drafting the code was. When the reviewer lacks them too, the change merges and the cost arrives later, a pattern we traced in the institutional memory gap behind AI code failures.

This is also why the problem grows with the organization. Every added team creates decisions that other teams' assistants cannot see. Every added tool creates another place where context has to be maintained by hand.

The Four Layers of Context Your Assistants Can't Reach

It helps to be precise about what "context" means, because most tooling conversations treat it as one thing. There are four layers, and today's assistants are strong on the first two and close to blind on the last two.

The repository layer has improved quickly. AGENTS.md gives coding agents a predictable place to find build steps, tests, and conventions, it is used by more than 60,000 open-source projects, and it is now stewarded by the Agentic AI Foundation under the Linux Foundation ^[6]. If your repositories do not have one, add it. It is the cheapest context improvement available.

It is also scoped to one repository by design. An instruction file cannot tell an assistant that a different team deprecated an API last week, and copying the same policy paragraph into forty repositories creates forty copies to keep current. The file format is fine. The organization and ownership layers simply do not belong to any single repository.

DORA's 2025 research reaches a compatible conclusion from survey data. Its report describes AI as an amplifier of what is already present in a team, finds that AI adoption now relates positively to delivery throughput while still relating negatively to delivery stability, and identifies seven capabilities that magnify AI's benefits ^[3]. Two of the seven are "AI-accessible internal data" and a "clear and communicated AI stance" ^[4]. Both are statements about the organization layer.

Why Adding Another Tool Makes It Worse

The common response to an underperforming assistant is a second assistant. A testing assistant joins the coding assistant, then a review bot, then a documentation agent. Each purchase is reasonable on its own.

Each tool also arrives with its own memory and its own configuration. One reads a rules file, another keeps per-account notes, a third indexes the code it was pointed at. None of them shares what it learned with the others, and none of them can be read by the person accountable for what ships.

The costs are practical:

- Duplicate maintenance. The same convention is written into several tool-specific files, and the copies diverge within weeks.

- Onboarding load. A new engineer has to learn the tools and also learn which tool knows what.

- Inconsistent enforcement. A security policy applied by the review bot is unknown to the coding assistant, so violations are generated first and caught second.

- No shared answer. When two tools disagree about the right pattern, there is no authority to settle it.

- Invisible to leadership. None of these memories can be opened by a CTO or compliance officer who wants to know what rules are actually being applied.

The alternative is not fewer tools. Developers have strong preferences, the tools are improving monthly, and forcing a single assistant across an organization trades one problem for another. The alternative is one shared source of context that every tool reads.

That has become practical because of the Model Context Protocol. MCP is an open standard for connecting AI applications to external systems, and it is supported by assistants such as Claude and ChatGPT and by development tools including Visual Studio Code and Cursor ^[5]. A context source exposed over MCP can serve whichever assistants your developers prefer, this year and next.

What a Shared Context Layer Has to Do

Before looking at any product, write down the requirements. A shared context layer that fixes the problems above needs five properties, and you can use them to evaluate anything, including a system you build yourself.

1. It holds intent, not only code. Indexing source code tells a tool what exists. It does not tell a tool what was decided, why, or what is no longer allowed.

2. It is typed. A policy, a decision, a constraint, and an open question are different things with different owners and lifecycles. Loose prose cannot be checked, filtered, or retired reliably. We cover the modeling side in why AI agents need an organizational ontology.

3. It spans repositories. The billing example fails inside a single-repo view. The layer has to see relationships between repositories and teams.

4. It stays current without heroics. If freshness depends on someone remembering to update a file, it will go stale. Ingest from real activity, plus a clear way for humans to correct it.

5. People can read it without a developer tool. Engineering leaders, security, and compliance need to see and steer the same record the assistants use.

A typed record for the billing decision could look like this. The shape is illustrative, and the important part is what it makes checkable:

kind: decision
title: Internal HTTP calls use the shared commons client
status: active
decided: 2026-06-12
owner: platform-team
applies_to:
  - all Python services
rationale: >
  Hand-rolled retry loops amplified load during the June billing
  incident. The shared client enforces backoff limits, tracing,
  and service authentication in one place.
supersedes: null
related:
  - kind: constraint
    title: Billing API v2 is removed after 2026-10-31
    owner: billing-team

With a record like this, the question "is this change appropriate here?" has an answer a machine can look up. The status says whether it still applies. The owner says who to ask. The rationale stops the next engineer from removing the rule because nobody remembers why it exists.

Where Connectory Fits Alongside the Tools You Already Use

Connectory is built as that shared layer. Genie organizational memory is a server-side record that stores people, teams, projects, and sources together with typed guidance (policies, decisions, objectives, constraints, and regulations) and the open questions nobody has answered yet ^[7]. It sits above your coding assistants and does not replace them.

Three kinds of readers use the same memory. Coding agents can check an idea, a plan, or a code change against it through MCP before a pull request exists. SlopBuster context-aware pull request review reads it at review time, so each pull request is judged against your organization's current decisions and the generic rules. People read and steer it from a dashboard, with no assistant or IDE installed.

In the billing example, the generated retry loop would meet the platform decision twice: once if the developer's agent runs an advisory check while planning, and again when the pull request is reviewed against the active decision and the API constraint. The reviewer's time goes to judgment, and the history lesson is already on the page.

Freshness comes from two directions. Connectory analyzes git activity across your organization's repositories for contributors, ownership concentration, and human versus AI-agent activity, and people update guidance in plain language. A policy changed today applies to the next review in every connected repository, with no files to copy.

Two scope notes matter if you are evaluating it. The agent-facing checks are advisory: they read organizational memory and do not change it. And the memory is only as good as the decisions recorded in it, so plan to seed it with the ten or twenty decisions that cause the most review churn and grow from there.

Run the Context Audit This Week

You can find out where your team stands without buying anything. Block ninety minutes with two senior engineers and one recent hire.

1. List your assistants and their memory. For each AI tool in use, write down what it reads for context and who maintains that source.

2. Pick five real decisions. Choose decisions from the last two quarters that affect more than one repository.

3. Test each decision against each tool. Ask whether the tool could know about it today. Record yes, no, or "only if someone copied it in."

4. Pull ten recent review threads. Tag every comment that supplies missing context ("we don't do it that way," "use the shared client," "ask the payments team"). Those comments are your context tax.

5. Ask the recent hire. Which of the five decisions did they learn from a document, and which from a correction?

The signal to track afterward is the share of review comments that supply context versus the share that exercise judgment. A falling context share means your assistants and your people are getting what they need before review. A flat one means new tools are adding drafts faster than your organization can explain itself.

If you do one thing in the next thirty minutes, do step 4 on a single pull request that took too long. Go back to the opening question while you read it: the assistant was fast, so where did the time go? The thread will show you.

Frequently Asked Questions

Do AI coding assistants make developers faster?

Often on individual tasks, and the tools keep improving. METR's early-2025 controlled trial measured experienced open-source developers taking 19% longer with AI allowed while believing they were faster ^[2]. METR's February 2026 follow-up says developers are likely more sped up now, and that selection effects leave it with only very weak evidence of how much ^[8]. Individual speed is also not team speed: DORA's 2025 research found AI adoption relates positively to delivery throughput and negatively to delivery stability ^[3]. Measure your own review and rework time before assuming a net gain.

Is a larger context window enough to fix this?

No. A larger window lets an assistant read more text from the places it can already reach. Decisions made in other repositories, in meetings, or in someone's head are not in any of those places, so they are not in the window at any size.

We already maintain AGENTS.md files. Do we still need shared memory?

Keep them. AGENTS.md is the right home for repository-level build steps and conventions ^[6]. Organization-level decisions, ownership, and cross-repository constraints need a single record that all repositories and tools read, or you will maintain the same policy in many files.

Do we have to standardize on one AI assistant?

No. An open protocol such as MCP lets different assistants read the same context source ^[5]. Standardize the memory and let developers choose the tools.

How does this help security and compliance teams?

A typed record of policies and decisions, with owners, dates, and rationale, gives reviewers and auditors one place to inspect current rules and review evidence. It also means a new security policy reaches every assistant and every review at once.

References

[1] Stack Overflow, "2025 Developer Survey: AI," 2025. https://survey.stackoverflow.co/2025/ai

[2] METR, "Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity," 2025. https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/

[3] Google Cloud, "Announcing the 2025 DORA Report: State of AI-Assisted Software Development," 2025. https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report

[4] DORA, "Capabilities Catalog," 2025. https://dora.dev/capabilities/

[5] Model Context Protocol, "What is the Model Context Protocol (MCP)?," 2026. https://modelcontextprotocol.io/docs/getting-started/intro

[6] AGENTS.md, "A simple, open format for guiding coding agents," 2026. https://agents.md/

[7] Connectory, "Organizational Memory (Genie)," 2026. https://www.connectory.ai/memory/

[8] METR, "We are Changing our Developer Productivity Experiment Design," 2026. https://metr.org/blog/2026-02-24-uplift-update/