---
id: "lib-2026-10-22-context-engineering-for-coding-agents-across-1"
type: "library"
title: "Context Engineering for Coding Agents Across 1,000 Repos"
lang: "EN"
org: "LinkedIn (InfoQ)"
source_type: "Other"
date: "2026-10-22"
week: "2026-W43"
url: "https://nosov.ai/library/lib-2026-10-22-context-engineering-for-coding-agents-across-1/"
original_url: "https://www.youtube.com/watch?v=ISdTqzYQiHg"
tier: "B"
tier_name: "Useful, limited"
tier_reason: "A LinkedIn platform engineer gives a detailed large-company design for agent context, ownership and tool limits, but the usage and productivity figures are self-reported with no measurement method."
summary_basis: "transcript"
original_minutes: "50"
tags: ["coding agents", "context engineering", "mcp", "developer productivity"]
frames: ["tacit-to-explicit", "solow-paradox"]
---

# Context Engineering for Coding Agents Across 1,000 Repos

Tier B (Useful, limited): A LinkedIn platform engineer gives a detailed large-company design for agent context, ownership and tool limits, but the usage and productivity figures are self-reported with no measurement method.

Summary based on the full transcript.

## In short

A 50-minute InfoQ talk (uploaded 22 October 2026) by Ajay Prakash, software engineer at LinkedIn, on making coding agents such as GitHub Copilot useful on a stack of thousands of repos and microservices built on internal frameworks. Early "vibe coding" failed because agents lacked internal context and engineers ended up supervising them. LinkedIn's answer was one local MCP server on every company laptop, exposing internal tools plus "playbooks": short named procedures that work as procedural memory and that agents themselves propose updates to.

## Key numbers

- 600: playbooks (agent-readable procedures) in LinkedIn's catalogue, described as over 600 workflows
- 8,000: people using the MCP server or its tools daily, including product managers, designers and TPMs
- 30: exposed tools beyond which agents slow down and degrade, per the speaker
- about 20%: productivity increase claimed in Q&A, method not stated

## What it reports

- Step 1: existing code search across about 1,000 repos wrapped as an MCP tool, then docs and wiki readers, feature flags, task management and the data platform. Richer context, but moderately complex tasks still failed.
- Three failure modes named: tribal knowledge spread across docs, chat and senior engineers' heads; context overload from tool output leading to compaction and loops; no long-term memory, so repeat tasks rediscover context.
- Step 2: playbooks (name, description, instructions) served as MCP tools, built before Anthropic's agent skills existed. One playbook does one thing; small ones compose. At session end the agent records outdated steps and opens a PR to fix the playbook.
- The server is pre-installed on all LinkedIn laptops and auto-updates every hour; OAuth is handled once with tokens in the keychain; every tool passes an InfoSec review.
- Beyond about 30 exposed tools agents slow down, so the catalogue sits behind three meta-tools (search, get schema, execute), scaling to thousands of tools.
- A central team owns the server and core tools; contributing teams own their playbooks; unused ones are deprecated on usage data.
- Top uses: incident debugging (runbooks converted to playbooks), boilerplate on internal frameworks, cleanup and migrations with self-verification steps, pipeline and infrastructure management, and setup for new joiners.
- Q&A: productivity up "about 20%", quality not decreased, reliability "has not gone down at all".

## How they got it

First-hand engineering account in a conference talk; the digest uses cleaned YouTube auto-captions. Usage counts presumably come from server telemetry; the productivity claim has no stated method or baseline.

## Limits

- The 20% figure, quality and reliability claims are unaudited and given in passing during Q&A.
- The 30-tool threshold is the speaker's observation, not a published test.
- The opening incident story is illustrative, not a measured case.
- Single company with unusual platform resources.

## Why it matters for companies

The transferable pieces are organisational: a central owner for the agent tool server, team ownership of each procedure, a security review gate per tool, and deprecation based on usage. Turning runbooks and onboarding knowledge into short, maintained procedures that agents can load on demand applies outside engineering too, to any process whose knowledge sits in a few people's heads. The tool-count limit is a practical design constraint worth testing before exposing every internal system to an agent.

Original: https://www.youtube.com/watch?v=ISdTqzYQiHg