Your AI Doesn’t Have a Model Problem. It Has a Context Problem

Everyone is shopping for a smarter model. Almost nobody is fixing the thing that actually limits AI value in software delivery: the context you feed it.

Frontier models are extraordinarily capable. Delivery outcomes have barely moved. That gap isn’t a capability problem, it’s a context problem. And it’s fixable.

Context, not the model

Four independent findings point the same direction.

Developers got slower, not faster. A METR randomised controlled trial (2025) put 16 experienced open-source developers on 246 real tasks in mature codebases. They were 19% slower with AI…, while believing they were 20% faster. The named factor: large, high-context-bar codebases the AI didn’t understand.

The gains shrink exactly where complexity rises. Stanford research analysing roughly 120,000 developers across 600+ companies finds a median lift of about 10–15%, because around half the gross gain is eaten by rework. On complex, mature, large codebases, the lift collapses or turns negative.

“Almost right” is the number one complaint. In the 2025 Stack Overflow Developer Survey (49,000+ developers), trust in AI accuracy fell to 29%, and 66% named their top frustration as “AI solutions that are almost right, but not quite.” Almost-right is the signature of bad context, not a weak model.

A bigger model doesn’t fix it. Veracode’s 2025 research across 100+ models found AI introduced security vulnerabilities in 45% of coding tasks and that rate stayed flat across GPT-4, GPT-5, Claude and Gemini generations. What changes the outcome is supplying standards and architectural constraints as context.

Meanwhile Gartner expects over 40% of agentic AI projects to be cancelled by end-2027, citing cost, unclear value and weak risk controls. Not model capability.

Why more context isn’t the answer either

The instinct is to dump everything into AI. The research says don’t.

• Lost in the Middle (Liu et al., TACL 2024): accuracy is highest when key information sits at the start or end of the context and degrades significantly when buried in the middle, even in long-context models.
• Context Rot (Chroma, 2025): across 18 leading models, performance becomes increasingly unreliable as input length grows, even on simple tasks.

So bloated context costs more and performs worse, at the same time. The goal isn’t maximum context. It’s the smallest set of high-signal, trustworthy tokens that gets the job done.

Your toolchain guarantees bad context

Here’s the structural problem. Delivery knowledge is scattered by design, and every handover point leaks context.

• Requirements live in Confluence, Jira, Azure DevOps and SharePoint — where they drift, duplicate and stay ambiguous.
• Test management sits in Zephyr, Xray, SAP or TestRail, so existing coverage is invisible to everything else.
• Code is in GitHub, GitLab or Bitbucket, but the why behind it lives in people’s heads.
• Automation in Playwright, Cypress or Selenium ends up detached from the requirements it was meant to prove.
• Reporting happens in spreadsheets and dashboards: manual, stale and un-traceable by the time anyone reads it.

Everyone contributes to product knowledge. Nobody owns it as a system. So people become the integration layer, and when you plug an agent into this, it stitches a picture from fragments and answers confidently whether those fragments are right or not.

Two root causes do most of the damage.

Documentation drift. GitHub’s Open-Source Survey found 93% of respondents hit incomplete or outdated documentation, while 60% of contributors rarely or never write docs. Academic work on documentation decay finds outdated code references persisting in popular projects for years. Point a tester, or an agent, at a stale page and you get confidently wrong test cases.

Ambiguous requirements. Boehm & Basili (IEEE Computer, 2001) put avoidable rework at 40–50% of development effort, naming hastily specified requirements as a major source. Requirements are where defects are cheapest to fix and the least tooled part of the lifecycle.

MCP doesn’t solve this

The Model Context Protocol is genuinely important. It standardises how agents connect to tools and data, killing the integration problem, and it’s now an open standard under the Linux Foundation with adoption across the globe.

But MCP standardises the connections, not the truth. An MCP server pointed at a stale Confluence space delivers stale context very efficiently. Provenance, freshness and ambiguity all sit upstream of the protocol.

What good context looks like

Five properties. Context must be:

1. Single source of truth: one fabric across fragmented tools, not another silo
2. Generated from source: reverse-engineered from code and real artefacts, not hand-written and hoped for
3. Kept in sync: drift flagged before it costs you next years AI budget
4. Traceable: every output linked back to where it came from
5. Governed, human-in-the-lead: access-controlled, auditable, validated by real people who own it

That last point is becoming a compliance matter too. The EU AI Act’s high-risk obligations around data governance, documentation, record-keeping and human oversight phase in from August 2026, with ISO/IEC 42001, DORA and NIS2 adding to the picture. Traceable context stops being a nice-to-have.

How SQAI Suite closes the gap

Roughly 80% of the effort of delivering software sits outside the code editor. Analysis, specification, testing, review, coordination, reporting. Almost all AI investment has gone into the 20% inside the IDE.

SQAI Suite targets the other 80%, as an orchestration layer that connects your existing stack rather than replacing it.

Three capabilities map straight onto the five properties above:

• Virtual Analyst generates technical and functional documentation from multiple sources, flags documentation drift before it costs you, and keeps diagrams in sync. Taking care of context rot, at the root.
• Virtual Testing delivers AI-native test management, AI-generated test cases on every test level, and ready-to-run automation in your own framework, anchored to structured up-to-date and complete requirements, not guesswork.
• Quality Cockpit provides analytics across teams and releases, early risk signals, and traceability from requirement to test run.

The workflow runs Baseline → Analyse → Test → Automate → Manage, with a human in the lead at every step, so ambiguity surfaces before test cases get written. And because SQAI assembles trusted context once and routes each task to the best-fit model, you’re never locked to a single LLM provider, next to that MCP connects it directly to your IDE copilots.

Your context-readiness checklist

Use this whatever vendor you choose.

• One source of truth, or N fragmented ones?
• Documentation generated from source, or hand-maintained and stale?
• Drift detected automatically, or discovered when a test fails?
• Requirements structured and testable, or prose?
• Does every AI answer show its sources?
• Traceability from requirement to test run?
• A human validating at each step?
• Are you measuring rework, not just output speed?

That last one is the box most teams skip. If you can’t measure churn, you can’t claim ROI.

Curious where your own context stands? We run scoped pilots with measurable outcomes agreed up front — a low-risk way to find out whether fixing context moves your numbers. Talk to us →