Engineering brief

Context engineering is the real bottleneck for coding agents at scale

InfoQ3 min read · saves 47 min

At a glance

The brief is enough

Relevance
Practical value
Radar
Time horizon
This year
Warnings
None

LinkedIn scaled coding agents across 1,000 repos by serving internal playbooks through MCP: 600 playbooks, 8,000 daily users, 20% productivity gain. The catch: agent performance degrades past 30 tools, so they built a search layer.

Coding agents fail without internal context; LinkedIn shows a production pattern for encoding tribal knowledge into agent workflows.

Watch if you are building or buying AI-assisted development infrastructure for a large, mature codebase with lots of internal context.

Summary

The system. LinkedIn built a context engineering layer for coding agents because out-of-the-box agents failed on its mature codebase. The company runs thousands of repos and services with custom databases, observability, feature flags, and experimentation systems. New engineers need a week-long bootcamp plus several weeks to become productive. Agents without access to that internal knowledge produced subpar code or hallucinated, so engineers stopped using them and went back to manual coding.

The mechanism. The core is an MCP server preinstalled on LinkedIn laptops, serving tools that wrap internal systems and playbooks that act as procedural memory. A playbook contains a name, description, and step-by-step instructions for a task like "write an Airflow pipeline" or "debug this service." Agents invoke playbooks as tools, so instructions enter the context window only when relevant.

Design rules. Playbooks are self-contained and composable. Each does one thing and can reference smaller playbooks, which gives progressive disclosure: an agent loads only the context needed for the current step and avoids context overload. This is essentially tribal knowledge turned into a navigable graph, with teams owning the playbooks for their workflows.

Scaling context. MCP performance degrades beyond roughly 30 exposed tools, so LinkedIn does not expose all tools directly. Instead three meta-tools let agents search the tool and playbook catalog by keyword and domain, fetch the schema for the chosen tool, then execute it. That is how 600 playbooks and thousands of tools stay usable without flooding the model.

Results. LinkedIn reports 8,000 daily users, including PMs, designers, and TPMs, and a 20% productivity gain with system reliability unchanged. The popular use cases are debugging and incident investigation, boilerplate code, migrations, pipeline management, and environment setup. The evidence is production experience, not a controlled benchmark, and the 20% figure is stated without methodology. No per-team breakdown or before-and-after comparison is given.

Maintenance. Playbooks go stale, so LinkedIn relies on agents to notice outdated instructions, improvise with code search and docs, and propose updates. Every tool and playbook goes through security review, and unused ones are aggressively deprecated. System reliability staying flat is the more meaningful signal. The lesson for engineering leaders is that internal context infrastructure, not model capability, determines whether coding agents deliver.

My take

I think the playbook pattern is the right bet for large organizations. Giving engineers agent tools without encoding how your systems actually work just produces babysitting work, and LinkedIn's MCP-based approach is a credible fix. The part I would push back on is the assumption that agents will keep playbooks current by improvising and self-updating. That depends on disciplined code review, ownership, and aggressive deprecation, which are organizational habits as much as technical features. The 20% productivity figure is too vague to justify investment on its own. What I would take from this is a pilot: pick one painful workflow, write a playbook, expose it through MCP, and measure whether trust in agent output improves before scaling to hundreds of playbooks.

What to do with this

  1. Pick one repetitive workflow, write a self-contained playbook, expose it through MCP, and measure agent success before expanding.
  2. Create an ownership and review process for agent playbooks, including security review and deprecation of unused entries.
  3. Ask your platform team to check how many tools are exposed to agents and whether a search layer is needed.

Watch the video

This video is blocked due to your privacy settings. To watch this video, please accept YouTube marketing cookies.

Related breakdowns

Get TL;DW

Too Long; Didn't Watch.

A concise breakdowns of the AI and devtools videos that actually matter for engineering leaders.

Free. Weekly. No hype.

Video and thumbnails remain the property of their respective creators. tldw.news provides editorial analysis, commentary, and discovery links to original content.