LinkedIn constrói camada de contexto para agentes de código com MCP

O problema: vibe coding não sobrevive à escala do LinkedIn

Quando o "agent mode" chegou às ferramentas de codificação em 2025 e Andrej Karpathy batizou a prática de vibe coding↳Vibe coding9 conteúdosO Vibe Coding e a Nova Era da Programação: Quando a Ideia Vira CódigoAI · ago 2025Vibe Coding com GitHub CopilotGestão Dev & TI · jul 2025Vibe coding: futuro da programação pode ser mais conversado do que escritoAI · mai 2025Ver tudo em AI →, times inteiros passaram a promptar em linguagem natural, sem olhar o código, confiando que os agentes fariam a coisa certa. No LinkedIn não funcionou assim, contou Ajay Prakash, engenheiro de software da empresa, em apresentação no QCon AI reproduzida pelo InfoQ (https://www.infoq.com/presentations/linkedin-context-engineering/). O motivo: a base de código do LinkedIn é grande e madura demais para caber no conhecimento pré-treinado de qualquer LLM.

A empresa tem milhares de repositórios e microsserviços interdependentes, construídos sobre frameworks internos em todas as camadas, com bancos de dados↳Banco de dados134 conteúdosSQL ou NoSQL: eis a questão!!Data · mar 2020Banco de dados: como organizar e dar segurança para milhões de dados de loteriasData · mai 20215 serviços gratuitos na cloud para bancos de dados PostgresData · fev 2025Ver tudo em Data → proprietários, sistema próprio de tracking e experimentação, observabilidade↳Observabilidade11 conteúdosObservabilidade para APIs: os desafios e benefícios dessa abordagemDev (Back & Front) · jan 2025Falhas em Observabilidade afetam os Apps e a Segurança das OrganizaçõesDev (Back & Front) · nov 2023ADK Java 1.0: O Google quer que você pare de gambiarra Python no seu backendMarketing Tech · abr 2026Ver tudo em DevSecOps → e gestão de configuração feitos sob medida para a escala do LinkedIn. Um engenheiro novo passa uma semana de bootcamp e ainda leva semanas para ficar produtivo só entendendo esses sistemas. Os agentes de codificação enfrentavam o mesmo obstáculo, só que sem bootcamp: erravam, alucinavam ou exigiam que o engenheiro os guiasse linha a linha, o que anula o ganho de produtividade prometido.

MCP entra em cena, mas resolve só parte do problema

A virada veio quando a Anthropic abriu o Model Context Protocol (MCP) e ele se tornou padrão de facto para conectar ferramentas a agentes; todas as ferramentas de codificação relevantes passaram a suportá-lo. O primeiro uso do LinkedIn foi embrulhar em MCP o motor de busca de código interno, que já indexava o código de mil repositórios com busca por keyword, regex e filtros de linguagem e tipo de arquivo. Com isso, o agente parou de depender só do que aprendeu em código open source e passou a consultar exemplos reais do próprio LinkedIn, inclusive lendo arquivos inteiros quando precisava.

Depois vieram ferramentas para buscar documentação e wikis, ler feature flags, sistemas de gestão de tarefas e a plataforma de dados. Cada ferramenta nova ampliava o contexto disponível, mas o time percebeu que, mesmo com acesso a tudo isso, os agentes travavam em tarefas um pouco mais complexas.

As três lacunas que continuavam travando os agentes

Prakash resume três problemas que sobreviveram à chegada do MCP:

• Conhecimento tribal: instruções de como instalar dependências, compilar ou testar um serviço específico ficam espalhadas em docs, wikis e threads de Slack, quando não estão só na cabeça de um engenheiro sênior. Nem com dezenas de ferramentas o agente achava essa informação, era procurar agulha em palheiro.
• Sobrecarga de contexto: cada chamada de ferramenta consome espaço na janela de contexto do modelo. Quando o agente precisa encadear muitas chamadas para montar o quadro completo, o sistema acaba compactando o histórico e perde informação, o que faz o agente entrar em loop, repetindo tool calls que já tinha feito.
• Ausência de memória de longo prazo: sem memória durável, o agente recomeça do zero a cada execução da mesma tarefa, o que consome tempo e queima muito token repetindo o mesmo trabalho de descoberta.

Playbooks: a memória procedural que fechou o ciclo

A resposta do LinkedIn foi dar aos agentes memória procedural, ou seja, contexto persistente de como executar uma tarefa. A empresa batizou isso de playbooks, servidos pelo mesmo MCP usado para as ferramentas de busca. Um playbook tem nome, descrição e instruções; o agente o descobre e invoca como faria com qualquer outra tool, e recebe de volta o passo a passo já validado para aquele tipo de tarefa.

Prakash cita como exemplo um playbook para configurar pipelines com Airflow: quando um engenheiro pede "monta um pipeline no Airflow para mim", o agente identifica que existe esse playbook disponível via MCP, invoca, recebe as instruções internas de como o LinkedIn estrutura esse tipo de pipeline e completa a tarefa com o contexto certo, sem precisar que alguém explique tudo de novo. Qualquer engenheiro do LinkedIn pode criar um playbook, o que transforma a curadoria de contexto em trabalho coletivo em vez de depender de um time central.

Esse mecanismo se aproxima do conceito de "agent skills", que a própria Anthropic abriria depois; segundo Prakash, o LinkedIn chegou a uma implementação equivalente por conta própria, antes desse recurso existir como produto.

O resultado que a empresa está mostrando

No caso descrito na abertura da apresentação, um agente conectado a esse conjunto de playbooks e ferramentas consegue identificar a causa de um alerta de latência, rastrear que o problema vem de um serviço downstream, achar o PR que introduziu o bug, resumir a causa raiz, propor a mitigação, atualizar o sistema de gestão de incidentes e ainda gerar um PR corrigindo o serviço afetado, tudo em poucos minutos, um trabalho que sem o agente levaria horas. Hoje a estrutura sustenta mais de 600 workflows desse tipo e milhares de ferramentas registradas no MCP interno. Segundo Prakash, o resultado agregado é 20% de ganho de produtividade sem perda de confiabilidade.

O que muda para quem constrói agentes por aqui

O padrão que o LinkedIn descreve não é exclusivo de big tech americana: é o problema que qualquer empresa brasileira com base de código legada e times grandes vai encontrar ao tentar colocar Copilot, Claude Code, Cursor ou qualquer agente para trabalhar de verdade em produção. Conectar um agente a um LLM genérico resolve autocomplete; fazer o agente confiável em cima do seu sistema proprietário exige tratar contexto organizacional como infraestrutura, com camada própria, versionamento e MCP como protocolo de transporte, não como acessório.

Na prática, isso sugere um roteiro: primeiro expor busca de código e documentação via MCP antes de qualquer coisa; depois, catalogar tarefas repetitivas, como abrir pipeline, debugar serviço ou revisar deploy, e transformá-las em playbooks versionados por quem realmente executa aquele trabalho no dia a dia, não por um time de plataforma isolado. O ponto que a apresentação deixa em aberto, pelo menos no material disponível, é como o LinkedIn garante qualidade e segurança dos próprios playbooks: quem revisa o que um engenheiro escreve como instrução para um agente, e como a empresa evita que um playbook desatualizado espalhe erro em escala. É a próxima pergunta que qualquer time que for copiar essa arquitetura vai precisar responder antes de confiar o merge em produção a um agente.

Fonte: InfoQ