Durant molt de temps, el debat sobre la intel·ligència artificial aplicada s’ha concentrat en una habilitat molt concreta: saber escriure bons prompts. Formular bé la pregunta, afinar el context, ajustar el to. Tot plegat ha estat útil i, en molts casos, imprescindible per treure profit dels models de llenguatge. Però el 2026 aquest enfocament comença a quedar curt ja que sembla que els prompts deixen de ser el centre del sistema.
El que separa avui una demo atractiva d’un producte que aguanta l’ús real no és tant la qualitat del text que s’envia al model, sinó l’estructura que l’envolta. El valor s’ha desplaçat cap al disseny del sistema: com es prenen decisions, com s’encadenen accions, com es gestionen errors, costos i responsabilitats.
El prompt engineering parteix d’una idea força senzilla: el model respon al que li demanes. Si la resposta no és bona, el problema és la pregunta. Aquesta lògica funciona raonablement bé en contextos puntuals, com ara assistents conversacionals, generació de contingut o suport bàsic, però comença a fallar quan els sistemes deixen de ser puntuals i passen a ser persistents, quan una interacció ja no és una resposta única sinó una seqüència d’accions amb conseqüències.
En aquests escenaris, el prompt deixa de ser una solució universal. Es pot escriure el millor prompt del món i, tot i així, obtenir un sistema fràgil, car o difícil de controlar.
El que realment està emergint són sistemes que operen amb objectius, no amb preguntes. Sistemes que planifiquen, executen, revisen i tornen a intentar-ho, sistemes que interactuen amb APIs, bases de dades, interfícies i, sovint, amb persones. En aquest context, el model és només una peça més, important, sí, però insuficient per si sola.
Aquí és on entra en joc l’arquitectura de decisions. No es tracta de què diu exactament el model, sinó de què se li permet fer, sota quines condicions i amb quins mecanismes de control.
Dissenyar aquest tipus de sistemes implica prendre decisions que abans no eren necessàries. I què ens cal?
- definir objectius clars i prioritzats
- establir límits d’acció explícits
- decidir quina memòria es conserva i quina es descarta
- preveure què passa quan el sistema no sap com continuar.
I tot això no es resol amb un prompt més llarg o més enginyós.
Un dels errors més habituals del moment actual és confondre capacitat del model amb qualitat del sistema.
Els models són cada cop més bons generant text plausible, raonant passos intermedis o escrivint codi, però aquesta millora pot donar una falsa sensació de seguretat. Fa que sistemes mal dissenyats semblin funcionar durant un temps, fins que entren en situacions límit: converses massa llargues, costos inesperats, accions irreversibles o errors difícils de rastrejar.
Aquí apareix un nou antipatró: agents que acumulen context sense control, que repeteixen accions innecessàries, que optimitzen mètriques equivocades o que prenen decisions opaques.
No és un problema del model, sinó de la manca d’arquitectura. S’ha delegat massa criteri sense definir prou bé el marc.
El més interessant d’aquest canvi és que el repte ja no és purament tècnic. S’assembla molt més al disseny d’organitzacions que al desenvolupament de software tradicional. Cal decidir qui pren decisions, amb quina informació, amb quins incentius i amb quina capacitat d’escalar problemes. En molts casos, aquestes preguntes no tenen una resposta correcta única, però ignorar-les acostuma a sortir car.
A mesura que aquests sistemes es despleguen en entorns reals, també es fa evident una altra necessitat: la governança. No n’hi ha prou que el sistema funcioni; cal poder explicar per què ha pres una decisió, qui n’és responsable i com es pot corregir si cal. Sense aquesta capa, qualsevol avantatge inicial es converteix en risc operatiu.
Tot plegat està transformant també els rols professionals. El perfil clau ja no és algú que sap “parlar bé” amb el model, sinó algú que sap dissenyar marcs de decisió. Algú capaç d’anticipar fallades, definir excepcions, limitar danys i equilibrar automatització amb control humà. És un rol més proper a l’arquitectura de sistemes o a la direcció tècnica que no pas a l’experimentació creativa amb prompts.
Això no vol dir que el prompt engineering desaparegui. Continuarà sent una habilitat útil, però deixarà de ser diferenciadora. Serà una competència bàsica, no un avantatge competitiu. El valor real es mourà cap a qui entén el sistema com un tot i sap on posar els límits.
El 2026, la pregunta rellevant ja no és com escriure millor el prompt, sinó com dissenyar millor la delegació. Quines decisions poden automatitzar-se sense risc,quines necessiten supervisió i quines no s’haurien de delegar mai.
Aquestes decisions no són neutres, i tampoc són només tècniques.
En aquest nou escenari, el llenguatge deixa de ser el centre i passa a ser un mitjà. El que importa és l’arquitectura que determina com, quan i fins on s’utilitza la capacitat del model.
Entendre això és el que separarà els projectes que escalen dels que es queden en demostracions brillants però fràgils.