Fonaments de programació amb IA

• Què és i per què importa
  • La IA com a amplificador
  • El patró de risc: generar, acceptar, publicar
• Com funciona la IA
  • Què és un LLM?
  • La capa d’orquestració
  • Context, tools i MCP
  • Assistent, agent i compleció inline
  • La data de tall de coneixement
  • Com portar informació actual al model
• Panorama actual
• Els riscos reals
  • Plausibilitat i al·lucinació
  • Quan la velocitat supera la comprensió
  • Deute tècnic i deute cognitiu

Aquest capítol recull la base conceptual: què són els LLMs, com funcionen les eines que els envolten, quin és el panorama actual i quins riscos introdueix la programació assistida per IA.

Guia pràctica per treballar amb eines IA de manera professional. Avui dia, saber-ne treure profit ja no és opcional — la diferència de productivitat entre qui les domina i qui no és massa gran per ignorar-la. L’objectiu no és usar menys la IA, sinó usar-la bé: sabent quan confiar-hi, quan revisar, i quan escriure el codi tu mateix.

Què és i per què importa

Saber treure profit de la IA ja no és opcional, però fer-ho bé tampoc és automàtic. La diferència entre una eina que accelera el treball i una que accelera la degradació del projecte depèn menys del model que de com el desenvolupador l’enfoca. Abans d’entrar en mecàniques, dos marcs que es repetiran al llarg de la guia: què fa la IA sobre qui la fa servir, i quin és el patró de fallada dominant avui.

La IA com a amplificador

La IA funciona com un amplificador. No t’ensenya res nou — projecta més fort el que ja portes a dins. Si tens criteri, context i disciplina, la IA amplifica la teva capacitat d’executar. Si no els tens, amplifica igual de bé els errors, els buits d’especificació i les decisions que no has pres. L’eina no discrimina; només fa més sorollós el que ja hi era.

El patró de risc: generar, acceptar, publicar

L’ús d’eines IA ja és habitual entre desenvolupadors professionals, i el patró de risc dominant és genera → accepta → publica: la IA produeix codi, el desenvolupador hi fa un cop d’ull ràpid, i el codi arriba al repositori. Andrej Karpathy ho va anomenar vibe coding: demanar a la IA, acceptar sense revisar, i publicar.

Aquest patró és el que la resta de la guia intenta evitar — no reduint la velocitat de generació, sinó fent que la comprensió i la verificació s’hi mantinguin al ritme.

Com funciona la IA

Abans de decidir com usar-la, cal entendre què fa realment una eina IA i quin tipus d’errors genera per defecte.

Què és un LLM?

Un LLM (Large Language Model) és el nucli de qualsevol eina IA moderna. Per entendre què és, cal construir la idea per capes:

1. Les dades: Es recullen quantitats massives de text — llibres, articles, pàgines web, codi font, documentació tècnica, fòrums, converses — que representen una fracció enorme del coneixement humà escrit.
2. L’entrenament: Una xarxa neuronal amb milers de milions de paràmetres processa tot aquest text. L’objectiu és simple: donat un fragment de text, prediu quina és la continuació més probable. Ajustant els paràmetres milions de vegades, la xarxa aprèn patrons estadístics del llenguatge — gramàtica, fets, raonament, estil, codi, lògica.
3. El model resultant: L’LLM és una funció matemàtica enorme que rep text i genera la continuació més plausible donat el context — no perquè hagi verificat que sigui veritat, sinó perquè s’ajusta a la distribució estadística apresa. No “sap” coses com una persona — ha comprimit patrons en els seus paràmetres. El que el fa interessant és que generalitza: pot combinar coneixements de dominis diferents per produir respostes noves — aplicar un patró vist en Java a un problema en Python, o explicar xarxes amb una analogia que ningú ha escrit mai.
4. Afinament i alineament: Després del preentrenament, el model base passa normalment per dues fases diferents. Primer, l’instruction tuning (supervised fine-tuning): es refina amb exemples de preguntes i respostes per aprendre a seguir instruccions i mantenir un format útil de diàleg. Després, sovint s’hi afegeix RLHF (Reinforcement Learning from Human Feedback) o tècniques similars d’alineament: humans comparen respostes, i el model s’ajusta per preferir les que semblen més útils, segures i adequades. La distinció importa: una fase ensenya com respondre a instruccions; l’altra intenta ajustar quines respostes preferir.
5. Com treballa amb informació actual? El coneixement après durant l’entrenament queda congelat, però el model pot treballar amb informació nova si la rep a la finestra de context (el text que el programa envia al model en cada interacció): documentació, resultats de cerques, fitxers del projecte. La intel·ligència és del model; la informació actual la proporciona el programa que l’envolta.

Aquesta manera de generar té una conseqüència directa: el model de vegades produeix respostes plausibles però incorrectes — el fenomen conegut com a al·lucinació. Funcions inventades, APIs inexistents, fets falsos: contingut que sona correcte però que no té base en cap font verificada. No és un error puntual sinó una propietat del funcionament — genera el text més plausible, no el més veritable.

L’LLM és el motor, però sol no fa res útil — necessita un programa que l’envolti per ser funcional. Aquest programa s’anomena capa d’orquestració (orchestration layer).

La capa d’orquestració

Entre tu i el LLM hi ha un programari que fa de pont: rep el teu prompt, munta el context que s’envia al model, interpreta la resposta i — si cal — executa accions sobre el sistema. És la capa d’orquestració, i és el que distingeix una eina IA d’una crida bruta a un model. Cinc conceptes clau per entendre-la:

• LLM (Large Language Model): El model de llenguatge descrit a la secció anterior — rep text, genera la continuació més probable.
• Finestra de context: Tot el text que l’eina envia al LLM en cada interacció: instruccions de sistema, fitxers del projecte, el teu prompt, historial de la conversa i resultats de tools. El LLM només veu el que hi ha dins d’aquesta finestra — res més.
• Tool (eina): Qualsevol capacitat que l’eina IA pot invocar: executar una comanda al terminal, llegir un fitxer, fer una cerca web, cridar una API. El LLM decideix quan cridar un tool; el resultat torna a la finestra de context. La majoria d’eines ja inclouen tools integrades (operacions amb fitxers, terminal, cerca al codi); el MCP (Model Context Protocol) és el protocol estàndard emergent per afegir-ne de noves — permet connectar eines externes (un repositori, una base de dades, un servei propi) a qualsevol agent compatible sense integració a mida cada vegada.
• Assistent IA: Una capa d’orquestració configurada per mantenir una conversa: rep el teu prompt, consulta el LLM i et retorna una resposta.
• Agent: Un assistent al qual s’afegeixen tools i que pot executar cicles autònoms de planificació i acció. El que distingeix un agent d’un assistent: l’agent no respon, actua.

La capa d’orquestració pot incorporar, a més de l’LLM principal, altres models especialitzats que treballen entre bastidors — per exemple, models d’embeddings (representacions numèriques de text que permeten cerques per similitud semàntica, no per paraula exacta) per cercar codi rellevant al projecte i carregar-lo a la finestra de context, o models més petits i ràpids per a la compleció inline.

No tots els LLMs serveixen per a qualsevol patró. Les capacitats concretes depenen de com s’ha entrenat cada model:

• Instruccions (instruction-tuned): El model entén i segueix instruccions en llenguatge natural — condició mínima per a un assistent o agent.
• Coneixement de codi: El model ha estat entrenat amb corpus de codi i genera codi idiomàtic en diversos llenguatges.
• FIM (Fill-In-the-Middle): El model pot completar un fragment de codi enmig d’un fitxer, no només al final. Capacitat imprescindible per a la compleció inline.
• Tool calling (function calling): El model sap generar crides estructurades a tools en el format que la capa d’orquestració espera. Sense aquesta capacitat, un agent no pot actuar.
• Context llarg: El model admet finestres de context grans (128k tokens o més — un token és un fragment de paraula: les paraules freqüents solen ser un token, les llargues o infreqüents es divideixen en varios; és la unitat en què el model mesura el text que pot processar), necessari quan l’agent ha de raonar sobre múltiples fitxers alhora.

Aquestes capacitats depenen del model, no de l’eina. Una eina pot exposar un botó d’agent, però si el model no té tool calling, l’agent no funcionarà.

El flux d’una capa d’orquestració segueix aquests passos:

1. Escrius un prompt.
2. La capa d’orquestració munta la finestra de context: instruccions de sistema + fitxers del projecte + historial de la conversa + el teu prompt nou.
3. El LLM rep tot el context i genera una resposta.
4. Si la resposta és text → la veus, s’afegeix a l’historial, fi.
5. Si la resposta és una crida a tool → el tool s’executa (terminal, llegir fitxer, escriure fitxer, cerca web, cridar una API…).
6. El resultat del tool s’afegeix a la finestra de context.
7. Torna al pas 3.

Context, tools i MCP

El pas 5 del flux anterior mereix un detall. El tool calling és una capacitat de doble cara: el model aporta la mecànica — saber generar crides estructurades — però quins tools pot invocar en cada sessió és decisió de la capa d’orquestració. El protocol reparteix la feina en tres rols:

• La capa d’orquestració exposa el catàleg. A cada crida a l’API hi afegeix la llista de tools disponibles, cadascun amb nom, descripció en llenguatge natural i esquema JSON dels paràmetres. El model no descobreix tools pel seu compte — només veu els que l’orquestrador li declara.
• El LLM demana el tool quan el necessita. Ha estat entrenat per reconèixer quan un tool aplica i emetre una resposta estructurada — típicament un bloc tool_use amb el nom del tool i els arguments en JSON que encaixa amb l’esquema rebut.
• La capa d’orquestració l’executa. Intercepta la crida, executa el tool real (terminal, API, base de dades…) i torna el resultat com a tool_result a la petició següent. El LLM mai toca el sistema directament: només emet i rep text estructurat.

El catàleg, doncs, el composa la capa d’orquestració — la majoria de tools venen integrats al client, i el MCP (descrit més amunt) permet ampliar-ne el conjunt amb serveis externs.

Assistent, agent i compleció inline

Del flux i el catàleg de tools en surten tres patrons d’interacció:

• Assistent (passos 1–4): escrius un prompt, reps una resposta de text, fi. Conversa pura, sense accions sobre el projecte.
• Agent (passos 1–7): el LLM no s’atura al pas 4 — crida tools, n’observa els resultats i continua actuant fins que decideix que ha acabat. Quan demanes a l’agent que implementi una feature, no respon un sol cop — llegeix fitxers, executa comandes, escriu codi i comprova resultats sense esperar la teva aprovació a cada pas.
• Compleció inline (autocomplete): un patró diferent que no segueix el flux anterior. El model suggereix codi constantment mentre escrius, i tu acceptes o rebutges amb una tecla. No hi ha prompt explícit ni bucle d’agent — és un flux continu de micro-decisions. Els riscos descrits en aquesta guia s’hi apliquen igualment, però a una escala on la revisió conscient és més difícil: cada suggeriment sembla petit i inofensiu, i l’acceptació es converteix fàcilment en un reflex.

En tots tres casos, la mecànica és simple. I en tots tres, el problema de fons és el mateix: el LLM no busca “la resposta correcta” — genera text plausible donat el context. Això vol dir que la sortida sembla correcta fins i tot quan no ho és. Tota la resta d’aquesta guia existeix per gestionar aquesta realitat.

La data de tall de coneixement

La finestra de context permet portar informació nova al model, però no resol l’altre límit fonamental: el coneixement après durant l’entrenament queda congelat. Això es coneix com a data de tall de coneixement (knowledge cutoff date).

Per exemple, si el model va ser entrenat fins a l’abril de 2024, una API llançada el juny del mateix any simplement no existeix als seus paràmetres. Quan demanes que generi codi per a aquella API, no pot recolzar-se en intuïció entrenada: ha de confiar en la documentació que li passes.

Per què importa. La diferència entre “el model ha vist patrons similars durant l’entrenament” i “el model no ha vist res però pot llegir especificacions” pot semblar teòrica, però es nota clarament en pràctica:

• API vista a l’entrenament: el model ha vist milers d’exemples, entén les subtileses i pot generalitzar a casos no coberts per la documentació. El codi és confident i robust.
• API posterior a la data de tall: el model pot generar codi estructuralment correcte llegint la documentació, però sovint omet subtileses, casos límit o detalls de seguretat que hauria comprès si tingués la intuïció entrenada. El codi és igualment “plausible” — passa una lectura ràpida — però és menys robust.

Com combina finestra de context i data de tall. Són dos conceptes lligats però distints:

• Finestra de context: límit físic del que el model pot veure en una sola conversa. Existeix dins la sessió actual.
• Data de tall: límit permanent dels coneixements apresos durant l’entrenament. No es pot superar carregant fitxers — la intuïció no està allà.

La diferència és intangible però real: “havia de validar aquesta entrada”, “aquell paràmetre no es comporta com sembla”, “aquell cas límit va causar vulnerabilitats en APIs similars” — tot això vindria de l’entrenament, i no hi és. Compensar-ho requereix especificació explícita.

Conseqüència pràctica. Quan treballes amb tecnologia recent, el model no pot recolzar-se en la seva intuïció — ha de confiar en el que li especifiques. Amb tecnologia d’anys enrere, algunes omissions al prompt les cobreix l’entrenament; amb tecnologia recent, no.

Com portar informació actual al model

El programa que envolta el model pot compensar el coneixement congelat de diverses maneres, de menys a més complexitat:

• Injecció directa al context: Enganxar documentació, especificacions d’API o resultats de cerca directament al prompt. Senzill i immediat — funciona per a qualsevol cosa que càpiga a la finestra de context.
• RAG (Retrieval-Augmented Generation): Una base de dades vectorial indexa un corpus de coneixement (documentació interna, wikis, tickets). Quan arriba una consulta, recupera els fragments més rellevants i els injecta al context. Permet treballar amb corpus grans que no caben en una sola finestra. La BD no s’actualitza sola — depèn d’un pipeline extern que reindexitza els documents quan canvien (per batch periòdic o per event). Per a informació molt volàtil, el tool calling en viu és preferible.
• Tool calling amb fonts en viu: L’agent crida una eina en temps real — una cerca web, una API, una consulta a base de dades — i el resultat entra al context. A diferència del RAG, la informació és sempre fresca.
• Prompt de sistema o fitxers persistents: Context recurrent injectat automàticament a cada sessió — estàndards de codi, convencions d’equip, decisions d’arquitectura. L’agent ho té sempre present sense que l’usuari ho hagi de repetir cada vegada.
• MCP (Model Context Protocol): Protocol estàndard per exposar sistemes interns — wikis corporatius, gestors de projectes, repositoris, dashboards — com a tools que l’agent pot consultar dinàmicament. La via natural per connectar un agent a les eines de l’organització.
• Fine-tuning sobre dades pròpies: Reentrenar o adaptar els pesos del model amb dades de l’organització — documentació interna, codi, incidències resoltes. El coneixement passa a ser part del model. Útil per a estil, terminologia i patrons molt freqüents, però el problema de la data de tall reapareix: el coneixement afegit també envellirà.

La regla general per triar entre aquestes opcions:

• Informació petita i puntual —uns quants paràgrafs de documentació, el resultat d’una cerca— injecció directa al context. És la solució més simple.
• Corpus gran i relativament estable —documentació interna, bases de coneixement, wikis d’empresa— RAG. Permet treballar amb volums que no caben en una sola finestra.
• Dades volàtils o necessàriament fresques —preus, disponibilitat, registres en temps real, sistemes externs amb estat propi— tool calling en viu.

Panorama actual

Les eines de programació amb IA es diferencien sobretot per on treballen i quanta autonomia tenen. La diferència important no és tant la marca com la combinació de tres factors: accés al repositori, capacitat d’executar eines (terminal, git, cerca, MCP) i grau d’autonomia.

Claude Code, Codex, Aider, Cursor, Windsurf, Gemini CLI, Continue o Copilot cauen en algun punt d’aquest espectre, amb diferències en UX, autonomia i ecosistema. Un mateix producte pot ocupar diverses files segons el mode d’ús: Cursor o Copilot fan compleció inline, xat i mode agent; Claude Code té versió local i de núvol. Però la distinció estructural és aquesta: xat, assistent o agent; i web, editor, local o núvol.

Les eines purament de xat continuen sent útils per pensar i aprendre, però aquest document se centra sobretot en agents locals o integrats a l’editor: eines que poden llegir, editar i executar sobre un projecte real.

Els riscos reals

Un cop distingim entre xat, assistent, agent i compleció inline, el punt important ja no és què poden fer, sinó quin tipus de fallada introdueixen per defecte. Els riscos no venen d’una eina concreta, sinó de la combinació entre plausibilitat, velocitat i manca de verificació.

Plausibilitat i al·lucinació

La sortida de la IA sembla correcta fins i tot quan no ho és. El codi segueix convencions de noms, passa linters i es llegeix bé — fins i tot quan la lògica és incorrecta o falta gestió d’un cas límit. Quan un humà escriu codi incorrecte, deixa traces: noms de variables maldestres, comentaris de dubte, experiments comentats. El codi de la IA no té cap d’aquests senyals.

Una forma específica d’aquest problema és l’al·lucinació: el model inventa identificadors, signatures, flags de línia de comandes o comportaments d’API que semblen raonables però que no existeixen. Una funció parseJSON(str, {strict: true}) pot ser inventada perquè encaixa amb el que un altre parser fa; una crida a git push --preserve-branches pot aparèixer perquè sona plausible. El model no distingeix entre el que sap i el que interpola. Verificar contra documentació oficial o executar el codi és l’única defensa fiable.

Quan la velocitat supera la comprensió

Quan la velocitat de generació supera la velocitat de comprensió, el risc augmenta d’introduir errors lògics, vulnerabilitats i ineficiències que passen una revisió superficial. El desequilibri és estructural: llegir i entendre codi és més lent que generar-lo, i encara més lent que acceptar-lo amb un cop d’ull. Quan la dinàmica per defecte de la sessió és generar ràpid, validar a posteriori, la revisió es converteix en un coll d’ampolla que la pressió d’entrega sovint acaba saltant.

Deute tècnic i deute cognitiu

El patró genera → accepta → publica crea dos costos acumulats que es reforcen mútuament.

El deute tècnic és el concepte clàssic: dreceres — deliberades o accidentals — que fan els canvis futurs més difícils. La IA n’accelera la creació perquè la proporció entre codi produït i codi entès canvia dràsticament. Quan escrius a mà, cada línia ha passat pel teu model mental; produeixes codi al ritme que l’entens. Quan acceptes sortida de la IA, produeixes codi molt més ràpid del que pots raonar. Les dreceres embegudes — valors hardcoded, casos límit ignorats, abstraccions fràgils — s’acumulen a la velocitat de generació, no a la velocitat de comprensió.

El deute cognitiu és un cost específic de la IA: codi que existeix al repositori però que l’equip no entén en profunditat, perquè es va generar i acceptar sense comprensió completa. El codi funciona — els tests passen, els usuaris no es queixen — però ningú no el pot modificar amb confiança sota pressió, depurar-lo quan falla de manera inesperada, o explicar per què està estructurat així. El deute cognitiu és diferent del deute tècnic: el codi pot ser net, ben estructurat i seguir totes les convencions — zero deute tècnic en el sentit tradicional — però és opac per a l’equip que el publica. Quan un incident de producció toca aquell codi a les 2 de la matinada, la depuració triga més perquè ningú no va construir el model mental que escriure el codi hauria produït.

Els dos es componen: no pots simplificar el que no entens, i no pots refactoritzar amb confiança el que mai no has raonat. La mitigació no és generar menys codi — és entendre el que publiques. Com evitar que aquest deute s’acumuli és una qüestió d’ownership del codi, que es desenvolupa a Control i autonomia.