L'enginyeria de context (en anglès, context engineering) és la pràctica de dissenyar, estructurar i gestionar el context que reben els agents d'IA per produir resultats consistents, predictibles i alineats amb els estàndards del teu equip. En una frase: no és afinar el prompt, és construir el sistema que fa que qualsevol prompt produeixi un bon resultat. I és el que separa els equips que "fan servir IA" dels equips que la dominen.
La majoria d'equips de desenvolupament, en canvi, fan servir la IA com feien servir Stack Overflow fa deu anys: cada persona busca pel seu compte, troba el que funciona, i no comparteix l'après. Només que ara, en lloc de copiar snippets, escriuen prompts. I el resultat és el mateix: coneixement fragmentat, resultats inconsistents i una corba d'aprenentatge que es repeteix amb cada nou membre de l'equip. L'enginyeria de context és la sortida d'aquest patró.
L'evolució que la majoria d'equips no veu
L'adopció d'IA en desenvolupament de programari ha seguit un patró predictible. Cada fase resol un problema però en crea un altre:
Cada developer escriu els seus propis prompts. Funciona per a l'individu. No escala. El coneixement es perd quan algú canvia d'equip.
L'equip crea fitxers AGENTS.md o CLAUDE.md amb convencions i regles. El primer salt cap al coneixement col·lectiu. Però continua sent estàtic i limitat a un repositori.
La gestió del context d'IA es tracta com a infraestructura. Es versiona, es testeja, s'itera, es distribueix organitzacionalment. És una capacitat de l'equip, no una habilitat individual.
La majoria d'equips estan a la fase 1 o, com a molt, a la fase 2. Les organitzacions que estan a la fase 3 o 4 no necessàriament fan servir millors models. Fan servir millor context.
Què és context engineering (i què no és)
Context engineering no és prompt engineering amb un altre nom.
Prompt engineering se centra a formular una bona pregunta. Enginyeria de context se centra a construir el sistema que fa que qualsevol pregunta produeixi un bon resultat. El detall de per què afinar el prompt té sostre i construir el context no: enginyeria de context vs. prompt engineering.
Inclou:
- Disseny de context. Quina informació necessita la IA per al teu projecte: arquitectura, convencions, patrons, restriccions.
- Estructura i nivells. No tota la informació es carrega sempre. Progressive disclosure: el mínim per decidir, el complet per executar, el detallat sota demanda.
- Composabilitat. Contextos modulars que es combinen sense conflicte. Una skill per a testing, una altra per a code review, una altra per a documentació, coexistint.
- Versionat i testing. El context es tracta com a codi: es versiona en git, es testeja que s'activi correctament, s'itera basant-se en resultats.
- Distribució organitzacional. El que un developer descobreix, tot l'equip ho hereta. Automàticament.
En resum: context engineering és a la IA el que DevOps va ser a la infraestructura. La sistematització del que abans es feia de manera artesanal.
Skills: la formalització del context engineering
Anthropic ha publicat recentment un estàndard obert anomenat Agent Skills que formalitza aquests principis. Una skill és una carpeta que conté:
- SKILL.md (obligatori): Instruccions en Markdown amb metadades YAML.
- scripts/ (opcional): Codi executable per a validacions o transformacions.
- references/ (opcional): Documentació addicional carregada sota demanda.
- assets/ (opcional): Templates, recursos, exemples de referència.
El que és interessant no és l'estructura de carpetes. És el model mental que implica.
Progressive disclosure: la IA no carrega tot, carrega el just
El sistema fa servir tres nivells d'informació:
- Nivell 1 (metadades YAML): Sempre carregat. Li diu a la IA quan activar la skill. Mínim consum de tokens.
- Nivell 2 (cos SKILL.md): Es carrega quan la IA determina que la skill és rellevant. Instruccions completes.
- Nivell 3 (fitxers enllaçats): La IA els consulta només quan necessita detall addicional. Documentació, guies API, exemples.
Aquest patró és rellevant perquè resol un problema real: la finestra de context no és infinita. Més context no és millor context. Millor context és el context correcte en el moment correcte.
L'analogia que ho explica tot
Anthropic fa servir una analogia de cuina que és molt clara:
Tres categories de skills segons el problema que resolen
Anthropic ha identificat tres patrons recurrents en com els equips fan servir skills. Cadascun resol un problema diferent:
Categories de Skills segons cas d'ús
Output consistent i d'alta qualitat: documents, dissenys, codi, presentacions. Inclou guies d'estil, templates i checklists de qualitat integrats. No requereix eines externes.
Exemple: skill de disseny frontend que genera components seguint el teu design system.
Processos multi-pas amb metodologia consistent: sprint planning, onboarding, code review. Inclou gates de validació i loops de refinament iteratiu.
Exemple: skill que guia la IA pas a pas en la planificació d'un sprint fent servir dades de Linear.
Capa de coneixement sobre les eines que la IA ja té accés. Coordina múltiples serveis, incrusta expertise de domini, gestiona errors. Transforma accés en capacitat.
Exemple: skill de Sentry que analitza bugs en PRs de GitHub combinant dades d'error monitoring amb code review.
De skill individual a capacitat organitzacional
El que fa que context engineering sigui una disciplina i no només una tècnica és el canvi d'escala: de l'individual a l'organitzacional.
Les skills es poden distribuir a nivell d'organització. Això significa:
- Un admin desplega una skill i tot l'equip la té automàticament.
- Les actualitzacions són centralitzades. Quan algú millora una skill, tothom se'n beneficia instantàniament.
- La IA es comporta consistentment per a tots els membres de l'equip en el mateix projecte.
- L'onboarding s'accelera perquè els nous membres hereten mesos de coneixement col·lectiu.
Aquest és el salt que la majoria d'equips no ha fet. No és que les eines no ho permetin. És que no han reconegut la gestió del context com una responsabilitat d'enginyeria.
El problema real: Quan cada developer té els seus propis prompts, l'equip té N maneres diferents de fer servir la mateixa eina. Els resultats són inconsistents. El codi generat no respecta les convencions. I cada nou membre triga setmanes a ser productiu amb IA. No és un problema d'eines, és un problema de context.
Testing de context: tractar instruccions com a codi
Una de les pràctiques més interessants de l'estàndard de Skills és la proposta de testing. Si el teu context és un actiu d'enginyeria, s'hauria de testejar com a tal:
- Tests d'activació: La skill es carrega quan hauria? No es carrega quan no hauria?
- Tests funcionals: L'output és correcte? Les crides a APIs funcionen? Els edge cases estan coberts?
- Tests de rendiment: És millor amb la skill que sense? Quants missatges d'anada i tornada s'estalvien? Quants tokens es consumeixen?
Dades de comparació que proposa Anthropic per mesurar l'impacte:
- 15 missatges d'anada i tornada
- 3 crides API fallides
- 12.000 tokens consumits
- L'usuari torna a explicar cada vegada
- 2 preguntes de clarificació
- 0 crides API fallides
- 6.000 tokens consumits
- Execució automàtica del workflow
El concepte és simple: les instruccions que dones a la IA són un sistema, i els sistemes es mesuren.
La connexió amb Spec-Driven Development
Si això sona familiar, és perquè ho és.
A onext portem implementant els principis de context engineering en equips de desenvolupament des d'abans que existís el terme. En diem Spec-Driven Development (SDD): especificacions estructurades que guien els agents d'IA amb control, predictibilitat i traçabilitat.
La convergència és directa:
- La "constitució" del projecte en SDD és l'equivalent a un SKILL.md organitzacional: regles immutables que la IA ha de respectar.
- Els templates d'especificació són skills de categoria 1: documents i assets consistents.
- Els playbooks de prompts són skills de categoria 2: fluxos de treball automatitzats.
- El flux de code review per a IA és una skill de categoria 3: intel·ligència de domini aplicada sobre eines.
El que SDD ha demostrat: amb els 12 equips transformats, el patró signat amb clients el 2026 és ×7 velocitat de lliurament, 0 sprints perduts durant la transformació i −50% de time-to-production, amb +40% de consistència del codi i cada línia traçable a un requisit. L'enginyeria de context és la formalització d'aquests principis a escala d'indústria.
Per on començar
No necessites implementar-ho tot alhora. L'evolució natural és:
- Setmana 1-2: Crea un AGENTS.md o CLAUDE.md al teu repositori principal. Documenta les convencions que el teu equip ja segueix. La nostra guia d'instruccions compartides explica com fer-ho pas a pas.
- Setmana 3-4: Identifica 2-3 fluxos repetitius (code review, generació de tests, documentació) i crea instruccions específiques per a cadascun.
- Mes 2: Empaqueta les instruccions més efectives com a skills portables. Afegeix scripts de validació on tingui sentit.
- Mes 3+: Estableix un cicle de millora contínua: contribució, revisió, validació, distribució, feedback. Tracta el context com un producte intern.
La clau és començar petit, amb el que ja funciona, i escalar des d'aquí.
Preguntes freqüents
Què és l'enginyeria de context?
L'enginyeria de context (context engineering) és la pràctica de dissenyar, estructurar i gestionar el context que reben els agents d'IA —arquitectura, convencions, regles i domini del teu projecte— perquè produeixin resultats consistents i predictibles. No és afinar el prompt: és construir el sistema que fa que qualsevol prompt produeixi un bon resultat. És a la IA el que DevOps va ser a la infraestructura: la sistematització del que abans es feia de manera artesanal.
En què es diferencia de l'enginyeria de prompts (prompt engineering)?
El prompt engineering optimitza una pregunta concreta; l'enginyeria de context construeix el sistema que fa que totes les preguntes funcionin. Afinar prompts té sostre i no escala entre persones ni projectes; el context ben dissenyat (versionat, testejat, compartit) s'hereta per tot l'equip i millora amb cada iteració. Un és una habilitat individual; l'altra, una capacitat de l'organització.
Per què l'enginyeria de context és un avantatge competitiu?
Perquè tots els equips tenen accés als mateixos models —es comoditzen i milloren per a tothom per igual—. El que no es comoditza és el context: com configures la IA, què sap del teu negoci, quines convencions respecta, quins errors evita. Això és propi del teu equip, no es copia, i és el que fa que la mateixa eina rendeixi ×3 en una organització i res en una altra.
El context és l'avantatge competitiu
Tots els equips tenen accés als mateixos models. GPT-4, Claude, Gemini. Les eines es comoditzen. Els models milloren per a tothom per igual.
El que no es comoditza és el context. Com configures la IA, què sap del teu projecte, quines convencions respecta, quins patrons segueix, quins errors evita. Això és propi del teu equip. Això no es copia. Això es construeix.
Els equips que dominen context engineering:
- Obtenen resultats consistents sense dependre del developer que escrigui el prompt.
- Escalen el coneixement col·lectiu amb cada millora que qualsevol membre aporta.
- Redueixen l'onboarding de setmanes a dies.
- Generen codi que respecta l'arquitectura des del primer intent.
- Tracten la IA com un membre més de l'equip, no com un autocompletat sofisticat.
La pregunta no és si el teu equip farà servir IA. La pregunta és si el context que li proporciones serà artesanal o enginyeril. Aquesta decisió defineix els resultats.
Font principal: Aquest article està basat en la guia "The Complete Guide to Building Skills for Claude" publicada per Anthropic, combinada amb la nostra experiència implementant Spec-Driven Development en equips de desenvolupament a Espanya.
Lectura complementària: Spec-Driven Development: IA controlada i predictible | Instruccions compartides per a equips IA
Estàndard obert: Agent Skills és un estàndard obert publicat per Anthropic. Les skills són portables entre Claude.ai, Claude Code i l'API.
Jordi García es Tech Lead en onext. Trabaja en llevar la IA a producción gobernada en equipos de desarrollo y de producto —con Spec-Driven Development, ingeniería de contexto y verificación humana en cada paso— y firma los insights técnicos de onext sobre método, calidad y coste de la IA aplicada.
LinkedIn →