El Prompt Engineering ha mort. Visca el Context Engineering.
Durant un parell d'anys, el Prompt Engineering es va vendre com la nova habilitat imprescindible.
Cursos, certificacions, llocs de feina, fils sencers plens de "frases màgiques" que suposadament desbloquejaven millors respostes en qualsevol model.
Escriu-ho així, no d'aquesta altra manera. Afegeix "pensa pas a pas". Dona-li un rol. Promet-li una propina si fa una bona feina.
Jo també m'ho vaig creure una mica, si més no al principi.
Però si heu passat temps de debò utilitzant Coding Agents sobre un projecte real, no sobre un exemple de joguina, ja sabeu cap a on va això.
El prompt era perfecte. El resultat no.
Fa un temps vaig demanar a un Coding Agent que implementés una feature força senzilla.
No vaig improvisar el prompt. Vaig descriure la feature amb detall, el comportament esperat, fins i tot un parell d'edge cases que volia coberts.
Segons qualsevol manual de "Prompt Engineering", era un bon prompt.
I tot i així, l'agent va afegir una nova abstracció on un helper que ja existia resolia el problema dos arxius més enllà. Va ignorar una convenció del projecte que segueixo des de fa anys. Es va inventar una dependència que mai vaig demanar.
No hi havia res malament en el prompt. El que faltava no era al prompt en absolut: era tot el que hi havia al voltant i que mai vaig donar a l'agent. Res d'això vivia en un CLAUDE.md, en una Skill, ni en cap altre lloc al qual l'agent pogués accedir de debò. Només vivia al meu cap.
El Prompt Engineering optimitzava la capa equivocada
El Prompt Engineering parteix de la idea que el coll d'ampolla és com preguntes.
La redacció, els exemples, el role-play, els trucs de format, les instruccions "pas a pas". Tot això pot millorar de veritat una resposta aïllada.
Però un projecte de software real no és una resposta aïllada. És arquitectura, convencions, història, compromisos tècnics, restriccions que només viuen al cap de les persones, i decisions que ningú va escriure perquè "tot l'equip ja ho sap".
Un agent que només rep un prompt ben escrit es queda sense tot això. I cap redacció enginyosa arregla la informació que falta.
La veritable palanca és el context, no la redacció
El que realment canvia la qualitat del que produeix un agent és si sap:
- Què esteu intentant construir, més enllà del ticket immediat.
- Quines restriccions existeixen ja al projecte.
- Quina arquitectura s'espera que respecti.
- Quines convencions segueix el projecte.
- Quines eines pot utilitzar.
- Quins límits no ha de creuar.
- Quines validacions ha d'executar abans de donar alguna cosa per acabada.
Res d'això cap en un sol prompt. Ha de viure en algun lloc al qual l'agent pugui accedir de manera constant — i avui aquest "algun lloc" té noms concrets. Un fitxer CLAUDE.md o AGENTS.md per a convencions, arquitectura i límits. Skills per a procediments que vols que se segueixin sempre igual, en lloc de reexplicar-los a cada sessió. Servidors MCP per a les eines i dades externes que l'agent té permès tocar. Hooks per a validacions que s'executen automàticament, perquè la correcció no depengui que l'agent recordi comprovar-ho.
Aquest és el salt del Prompt Engineering al Context Engineering: de "com redacto aquesta petició" a "què necessita saber l'agent, i on ha de viure aquest coneixement, per prendre bones decisions sense mi".
Més context no és automàticament millor context
Aquí ve la part que sorprèn qui comença a prendre's això seriosament: donar-li a un agent més documents, més eines i més instruccions no millora el resultat de manera fiable.
Un mur de regles desactualitzades a AGENTS.md és pitjor que no tenir el fitxer. Deu servidors MCP connectats perquè "algun dia podrien ser útils" són pitjors que tres que l'agent realment sap quan fer servir. Dues Skills que se solapen i es contradiuen en silenci són pitjors que una de sola i clara. Un context que es contradiu a si mateix és pitjor que cap context, perquè ara l'agent ha d'endevinar quina part creure's.
El Context Engineering no consisteix a maximitzar la quantitat d'informació. Consisteix a seleccionar-la: mantenir-la precisa, rellevant i fàcil de fer servir per a l'agent.
Dissenyar l'espai de decisió, no només la petició
Aquesta és la part que crec que més canvia el paper d'un enginyer sènior.
El Prompt Engineering tracta l'agent com una màquina expenedora: hi poses la moneda correcta, en surt el snack correcte.
El Context Engineering el tracta més aviat com l'onboarding d'una nova incorporació. No li donaries a un desenvolupador nou un ticket d'una línia i marxaries. Li donaries el codi, la guia d'estil, un parell d'exemples de PRs acceptades i per què, i una llista clara del que no ha de tocar.
Això és exactament el que faig ara en els projectes on faig servir Coding Agents seriosament: instruccions de projecte en un CLAUDE.md, Skills per als patrons que vull que es repeteixin exactament igual, permisos explícits d'eines perquè l'agent no pugui anar més enllà dels seus MCPs autoritzats, i una llista curta de comprovacions — tests, lint, un pas de revisió — que ha d'executar abans de poder donar alguna cosa per acabada.
El prompt segueix aquí. Simplement ja no és el més important.
La segona feina que corre en paral·lel: mantenir l'agent, no només donar-li prompts
Quan el context passa a viure en fitxers, Skills i configuracions d'eines en lloc del teu cap, apareix un tipus de feina nova — una que el Prompt Engineering mai va haver de contemplar, perquè assumia que tot passava dins d'un únic torn de xat.
Una sessió amb un Coding Agent no és només: escriure el prompt, esperar el resultat, validar-lo i passar a la següent tasca. Per sota, cada iteració t'obliga en silenci a preguntar-te també:
- Està l'agent ben definit per a aquest tipus de tasca, o estic improvisant context sobre la marxa una altra vegada?
- Hauria d'actualitzar les seves instruccions — el
CLAUDE.md, l'AGENTS.md? - Aquesta tasca necessita una Skill nova, o li falta un cas a una que ja existeix i que acabo de trobar?
- Està l'agent fent servir la Skill o l'MCP correctes, o triant l'eina equivocada perquè dues s'assemblen?
- Acaba de creuar un límit que jo pensava que ja havia fixat — i si és així, on hauria de viure realment aquest límit?
Res d'això és escriure un prompt. És mantenir el sistema en què treballa l'agent, sessió rere sessió.
I aquí és on es torna car: quan el resultat està malament, sempre hi ha dues sortides.
La ràpida és reexplicar-l'hi al xat — reformular, afegir el detall que faltava, corregir-ho sobre la marxa i continuar. Funciona, per a aquella sessió.
La bona és arreglar-ho on realment es quedarà: actualitzar la regla del CLAUDE.md, editar la Skill, ajustar la descripció d'una eina en un MCP, afegir l'exemple que faltava. Costa més ara mateix, però s'amortitza a cadascuna de les sessions següents.
Jo mateix m'he enxampat més d'una vegada agafant la drecera — explicant la mateixa restricció d'arquitectura per tercera vegada en una setmana, en lloc de dedicar cinc minuts perquè sigui impossible tornar-la a passar per alt.
El temps que estalvies escrivint codi, l'inverteixes definint l'agent
Aquest és el trade-off que ningú menciona quan es parla de "productivitat 10x amb IA".
Els Coding Agents sí que estalvien temps escrivint, en boilerplate i en primers esborranys. Però si t'ho prens seriosament, aquest temps no desapareix: es desplaça. Es desplaça a escriure i mantenir Skills, a seleccionar què entra a AGENTS.md, a decidir quins servidors MCP mereixen de debò una connexió permanent, i a revisar si l'agent va triar l'eina adequada per a la feina.
El Context Engineering no és una configuració que fas una vegada abans de començar "la feina de veritat". És feina de configuració contínua que competeix per les mateixes hores que l'agent suposadament t'havia d'alliberar.
Els enginyers que en treuen valor de debò no són els que redacten bé el prompt en el moment. Són els que tracten cada mal resultat com un senyal sobre el sistema, no només sobre aquella petició concreta — i que estan disposats a reinvertir part del seu temps estalviat a arreglar-ho allà.
Conclusió
El Prompt Engineering no està malament. Simplement està incomplet, i cada cop és més irrellevant per si sol.
L'habilitat que realment separa un resultat útil de soroll car és dissenyar — i mantenir contínuament — el context en què opera un agent: el CLAUDE.md que llegeix, les Skills a què pot recórrer, els MCPs que pot invocar i les comprovacions que ha de superar. Aquest manteniment és feina real, i és allà on acaben anant a parar les hores que la IA suposadament t'havia d'estalviar.
Al pròxim article d'aquesta sèrie aprofundiré en el Harness Engineering: els sistemes, eines i comprovacions que construïm al voltant d'un agent perquè el context deixi de ser un prompt puntual i es converteixi en l'entorn en què sempre treballa.
Fins llavors, la pregunta que val la pena fer-se no és:
Quin és el millor prompt per a això?
És:
Què necessita saber aquest agent — i on hauria de viure realment aquest coneixement — per prendre la mateixa decisió que prendria jo?
Si esteu construint workflows semblants al voltant de Coding Agents, m'agradaria molt comparar notes — no dubteu a escriure'm.