LinkedIn's codebase is enormous: thousands of repositories, thousands of microservices, custom-built databases, internal frameworks at every layer, and a configuration system so complex that new engineers spend their first week in a dedicated bootcamp just learning the lay of the land. When the company gave its engineers access to coding agents like GitHub Copilot, the results were underwhelming. The agents could generate syntactically valid code, but they had no idea how things were actually done at LinkedIn. Engineers ended up babysitting the agents instead of getting help from them, and many went back to manual coding to hit their deadlines.
Ajay Prakash, a software engineer at LinkedIn, described the company's solution at a recent InfoQ presentation: a system called Contextual Agent Playbooks and Tools that gives coding agents institutional memory. The system now supports over 600 workflows and thousands of tools, and it has fundamentally changed how LinkedIn engineers work on internal systems.
The Problem With Vibe Coding at Scale
When Andrej Karpathy coined "vibe coding" in early 2025, the appeal was straightforward: prompt an agent in natural language, let it figure out the changes, and trust the terminal output to tell you if something broke. For personal projects or small codebases, the approach works. For LinkedIn's stack, it did not.
The core issue is context. LLMs train on open-source code. They know how React, Spring, and PostgreSQL work in the abstract. They do not know that LinkedIn uses a custom tracking system, that deployments follow a specific pipeline, or that a particular service depends on three internal libraries with non-obvious configuration. Without that knowledge, agents produce code that compiles but fails at runtime, or they hallucinate APIs that do not exist.
LinkedIn's codebase compounds this problem at every level. The company runs thousands of repos containing microservices and applications that depend on each other through internal frameworks. Custom infrastructure handles everything from databases to experimentation platforms to observability. An engineer joining the company needs weeks to become productive because the tribal knowledge required to navigate the system is vast and scattered across wikis, Slack threads, and senior engineers' heads.
Coding agents faced the same bottleneck. They could not find the right context, and when they tried, the context overload problem made things worse. Every tool call consumes space in the model's context window. When agents made enough calls to gather the information they needed, the context filled up and got compacted, erasing critical details. The agents would then loop back, retracing steps they had already completed, wasting tokens and time.
MCP as the Foundation
LinkedIn's timing aligned with Anthropic's release and open-sourcing of the Model Context Protocol (MCP). MCP provides a standard way to connect external tools to AI agents, and every major coding tool adopted it. For LinkedIn, this was the integration point the company needed.
The first tool they connected was LinkedIn's existing code search engine, which indexes all code across the company's 1,000-plus repositories. Engineers already used this system to search by keyword, regex, file type, and language. Wrapping it in MCP let coding agents query the same corpus. Now, instead of guessing what LinkedIn code looks like, an agent could search for relevant examples, pull up file contents, and learn the patterns before generating anything.
Prakash highlighted that LLMs are strong at tool calling. Even with a vague natural language request like "show me a LangChain example," an agent can iterate through search queries, refining its approach until it finds what it needs. Adding code search unlocked this capability for LinkedIn's internal codebase.
LinkedIn continued layering tools. Agents could now search internal documentation and wikis, read feature flags, access task management systems, and query the data platform. Each new tool gave agents richer context, but the underlying problems persisted for anything beyond simple tasks.
Tribal Knowledge and the Limits of Tool Calling
The gap between "can find code" and "can do the job" turned out to be tribal knowledge. Knowing how to install dependencies, which build commands to run, how to test changes, or which team owns a particular service. This information lived in scattered documents and senior engineers' memory. Even with tools available, agents could not reliably locate the right pieces.
The second problem was that agents lacked durable memory. Every session started from scratch. If an agent figured out a complex workflow through extensive tool calls, the next time an engineer asked for the same thing, it would repeat the entire discovery process. The experience was slow, expensive in tokens, and frustrating for engineers who needed results quickly.
Playbooks as Procedural Memory
LinkedIn's answer was procedural memory, delivered through what they call playbooks. A playbook captures the steps and background knowledge an agent needs to complete a specific task. Each playbook has a name, description, and a set of instructions. The coding agent discovers playbooks as available tools via MCP, reads the description to understand what it covers, and invokes it when relevant.
When triggered, the playbook returns its full instructions as tool output. The agent receives all the context it needs in one call: which services to check, which commands to run, which patterns to follow, and which pitfalls to avoid. No searching through wikis. No compacting critical context out of the window. No starting over from zero.
Prakash used an Airflow pipeline as an example. An engineer asks the agent to set up a new pipeline. The agent recognizes that an Airflow playbook exists, invokes it, and gets the complete procedure: which repos to use, what configuration format is expected, which internal libraries handle scheduling, and how to test the pipeline before deployment. The playbook can also incorporate task-specific details the engineer provides, combining institutional knowledge with the immediate request.
Anyone at LinkedIn can write a playbook and commit it to a central repository. Once checked in, it becomes available to every other engineer using coding agents across the company. The system created a feedback loop where tribal knowledge gets formalized and shared rather than remaining locked in individual heads.
The Automation in Practice
Prakash walked through a concrete scenario to demonstrate the system's impact. An engineer on call receives a pager alert about a latency spike in a critical service. The engineer hands the alert link to a coding agent. The agent fetches LinkedIn's internal debugging instructions, identifies the affected service, pulls logs and metrics, traces the problem to a downstream dependency, finds a recent buggy code change in that dependency, creates a fix, mitigates the issue, updates the incident management system, and generates a detailed report. All of this happens in minutes instead of the hours it would take an engineer working manually.
The agent did not achieve this through general knowledge. It followed specific playbooks that encoded how to debug at LinkedIn, how to trace dependencies across services, and how to interact with the incident management system. Without those playbooks, the agent would have been lost in the first step.
What This Means for Large Organizations
LinkedIn's experience points to a broader pattern. The limiting factor for AI coding agents at enterprise scale is not model capability. It is institutional context. Models are good enough to write correct code if they know what correct looks like in a given environment. The hard work is building the systems that deliver that knowledge reliably, without overloading the context window or forcing engineers to re-explain the same context in every session.
The playbook model offers a practical template: wrap existing internal tools in MCP, capture tribal knowledge as structured instructions, and let agents consume both through a single protocol. For organizations with large, complex codebases, this approach turns coding agents from impressive demos into genuinely useful collaborators.