better

# Eines IA per al desenvolupament

<!-- toc -->

Índex del material dividit a partir de la guia original sobre programació amb IA.

- [Fonaments de programació amb IA](./aitools/01_fonaments.md)

# Fonaments de programació amb IA

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.

## Programar amb IA

<!-- toc -->

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

# Control i autonomia

Aquest capítol se centra en com limitar l'autonomia de l'eina, preservar l'ownership del codi i decidir en quin entorn és segur deixar actuar un agent.

<!-- toc -->

## Com mantenir el control

Aquest capítol se centra en com limitar l'autonomia de l'eina, preservar l'ownership del codi i decidir en quin entorn és segur deixar actuar un agent.

Treballar bé amb IA no vol dir delegar més decisions, sinó saber quines continues prenent tu i quan convé limitar l'autonomia de l'agent.

### Els modes de treball: Chat, Plan i Autònom

## Els modes de treball: Chat, Plan i Autònom

L'espectre **Chat / Plan / Autònom** descriu quanta autonomia dones a l'eina — fins on la deixes actuar abans d'intervenir. El mode Chat és l'extrem conversacional: l'eina llegeix i raona, però no toca res.

Les tasques tedioses o senzilles són el punt de partida natural per delegar: si la feina és tediosa, normalment és perquè les decisions de disseny ja estan preses (condició 1) i el resultat esperat és prou clar per descriure'l sense ambigüitat (condició 2); i com que saps exactament què ha de sortir, verificar-ho és directe (condició 3).

#### Triar el mode: exemples concrets

### Triar el mode: exemples concrets

| Situació | Mode | Per què |

| -------- | ---- | ------ |

| Projecte greenfield, fase d'arquitectura | **Chat → Plan** | No existeixen patrons encara; la càrrega d'especificació és màxima |

| Intuïció o idea vaga que vols validar | **Autònom → revert** | El cost d'explorar és baix; genera un esborrany, avalua'l, reverteix si no val la pena |

#### Compleció inline

### Compleció inline

Abans d'entrar a la resta de la guia — que cobreix tant l'assistent conversacional com els agents — val la pena cobrir la compleció inline, un patró diferent amb un cas d'ús més acotat i una pràctica poc recomanable per defecte.

La compleció inline no demana menys criteri que un agent; en demana un de més continu i menys visible.

#### Explorar idees amb cost baix

### Explorar idees amb cost baix

Els tres modes pressuposen que ja saps què vols construir. Però les eines IA — tant assistents com agents — canvien *què val la pena explorar*.

La trampa: que el cost d'explorar sigui baix **no vol dir que el cost de publicar ho sigui**. Qualsevol cosa que passi d'exploració a producció necessita la mateixa revisió, comprensió i verificació que la resta de codi — tot el que descriu aquesta guia segueix aplicant-se. El risc és tractar la sortida exploratòria com a codi definitiu.

### Qui pren les decisions

## Qui pren les decisions

La velocitat d'execució que ofereix la IA fa temptador delegar-ho tot, incloent-hi decisions que defineixen l'estructura del projecte. Però la qualitat del resultat depèn directament de quines decisions pren el desenvolupador i quines delega.

Aquí és on la col·laboració entre humans guanya rellevància, no en perd. Quan un desenvolupador treballa sol amb la IA — sigui un assistent o un agent — la interacció és asimètrica: la IA no empeny cap enrere, no qüestiona supòsits, no diu "això no encaixa amb el que vam decidir la setmana passada". La discussió entre desenvolupadors — en una revisió de codi, en una sessió de disseny, o en *pair programming* — força exactament el pensament crític que la interacció amb la IA no activa. El *pair programming* amb humans no desapareix per la IA: es desplaça d'implementació (on la IA és més ràpida) cap a decisions de disseny i avaluació de la sortida (on la discussió humana és insubstituïble).

#### Què decideix el desenvolupador, què fa la IA

### Què decideix el desenvolupador, què fa la IA

La distinció fonamental és entre decisions de disseny i treball d'implementació:

  - *El desenvolupador decideix* quin patró seguir (repositori, servei, pipeline...) i per què encaixa al projecte.

  - *La IA implementa* el codi que aplica aquell patró de manera consistent.

- **Fronteres entre mòduls**

  - *El desenvolupador decideix* on acaba un mòdul i on comença un altre, quines responsabilitats té cadascun. Per a tipologies de fronteres i mecanismes de separació, vegeu [Arquitectura i fronteres](disseny.md#arquitectura-i-fronteres).

  - *El desenvolupador decideix* on acaba un mòdul i on comença un altre, quines responsabilitats té cadascun. Per a tipologies de fronteres i mecanismes de separació, vegeu [Arquitectura i fronteres](../fonaments/disseny.md#arquitectura-i-fronteres).

  - *La IA implementa* els imports, les connexions internes i el cablejat entre mòduls.

- **Interfícies públiques**

  - *El desenvolupador decideix* les signatures, els tipus de retorn i el contracte d'errors de cada funció exposada.

Un check útil abans d'acceptar qualsevol sortida de la IA sobre una decisió estructural: **podries explicar per què és la decisió correcta, i reconeixeries si fos incorrecta?** Si no, aquella decisió s'ha d'escalar, independentment de com de confiant soni la IA. L'abast correcte per a qualsevol tasca IA és aproximadament el màxim canvi que es pot revisar d'un cop — el mateix abast que usaries per a un PR humà.

#### Qui decideix: experiència i frameworks

### Qui decideix: experiència i frameworks

La sortida de la IA és plausible per defecte. Per a un desenvolupador amb experiència profunda en el domini, la plausibilitat és un punt de partida: aplica judici i empeny cap enrere quan quelcom no encaixa. Per a un desenvolupador que encara està construint judici arquitectural, la mateixa plausibilitat és una trampa: la sortida sembla correcta perquè encara no pot veure què hi falta.

El criteri es construeix amb un bucle lent: decideixes, vius amb les conseqüències, veus què falla, entens per què. Els frameworks estalvien part d'aquest dolor; la IA n'estalvia encara més. El junior produeix codi coherent abans d'haver tingut temps de construir criteri propi — i això només funciona si coneix el framework prou bé per detectar quan la sortida de la IA se n'aparta. Si no el domina, la bastida deixa de protegir.

### Ownership del codi

## Ownership del codi

Tradicionalment, *code ownership* designa una responsabilitat administrativa: qui manté quin codi, qui aprova els canvis, qui consta al `CODEOWNERS`. Aquí fem servir el terme en un sentit més exigent: **ownership com a enteniment viu del codi**. No només "qui n'és responsable", sinó *qui el pot explicar, modificar amb confiança sota pressió, depurar quan falla de manera inesperada, i argumentar per què està estructurat així*. El deute cognitiu descrit a [Fonaments de programació amb IA](./01_fonaments.md#deute-tècnic-i-deute-cognitiu) és el símptoma d'aquesta ownership erosionada; aquí tractem com preservar-la.

- **Accepta el cost de la lentitud quan el codi és nou per a l'equip.** És millor produir menys codi que l'equip entén que molt codi que ningú no pot mantenir.

- **Reparteix el coneixement.** Si una sola persona ha vist el que la IA ha generat, l'ownership és individual, no d'equip — i quan aquesta persona no hi és, torna a zero. *Pair programming*, revisions compartides i walkthroughs en viu distribueixen el model mental.

### Execució aïllada i automatització

## Execució aïllada i automatització

Decidir què delega l'agent és només la meitat de la pregunta de control. L'altra meitat és **on corre** i **amb quanta supervisió**. Un agent que actua sobre el teu sistema host, amb les teves credencials i accés a xarxa, té un blast radius diferent d'un que corre en un contenidor efímer amb permisos mínims — encara que faci exactament la mateixa feina.

# Agent o solució determinista

Aquest capítol separa els casos on un agent aporta judici dels casos on una comanda, un script o una eina determinista resolen el problema millor.

<!-- toc -->

## Quan no cal un agent

Aquest capítol separa els casos on un agent aporta judici dels casos on una comanda, un script o una eina determinista resolen el problema millor.

Davant d'una tasca de desenvolupament, l'opció per defecte en un flux AI-first és demanar-la a l'agent. Però abans val la pena una pausa breu: la mateixa feina sovint la fa millor un **codi determinista** — terme paraigua que cobreix scripts (*shell*, Python), *one-liners* (`sed`, `awk`, `jq`), eines de refactoring de l'IDE, *regex*, *Makefiles*, *linters*, *code generators*, consultes SQL, o una funció escrita una sola vegada. Tot el que té un comportament reproduïble i una especificació explícita hi entra. Per concreció, en aquesta secció farem servir sovint la paraula *script* com a exemple, però la idea aplica a tot el ventall.

### Dos paradigmes, mateixes eines

## Dos paradigmes, mateixes eines

Hi ha dos paradigmes per resoldre una tasca:

El problema típic no és triar malament entre els dos paradigmes — és **no aturar-se a triar**: delegar a l'agent una tasca que era determinista, o intentar codificar amb regles una que demanava judici.

### Una pregunta a cada tasca

## Una pregunta a cada tasca

> Puc descriure aquesta tasca com una transformació amb regles clares — `f(input) → output`?

- **Si la resposta és sí**: tens un problema determinista. Vols un script, no l'agent.

- **Si la resposta és no**: cal preguntar-se *per què* no — la resposta determinarà si l'agent és realment la millor opció o si el que et falta és entendre el problema.

### Tres tipus de problema

## Tres tipus de problema

- **Determinista (formalitzable).** Les regles existeixen i les coneixes. Calcular la nota d'un examen, validar un format, executar tests, comptar ocurrències, transformar JSON. La feina és **implementar les regles**. Posar un agent al mig converteix una funció reproduïble en una resposta plausible.

- **Ambigüitat real (cal judici).** El problema depèn del context i no té una única resposta correcta. *"Refactoritza aquest mòdul perquè respecti el patró de `UserService`"*, *"per què falla aquest test inestable?"*, *"és segur aquest canvi de schema?"*. Codificar totes les heurístiques explícitament és inviable o es desactualitza ràpid. **És el cas legítim per a un agent.**

- **Desconeixement temporal del domini.** Les regles existeixen, però *encara no les coneixes*. És el cas més perillós: l'agent produeix sortida raonable, i això elimina la pressió per entendre-ho. La trampa: usar l'agent per *evitar pensar*, no per *raonar millor*. L'estratègia correcta és inversa — **explora el problema amb l'agent, entén-lo, i un cop el tens clar formalitza-ho en codi**.

### Senyals per decidir

## Senyals per decidir

Els tres tipus es tradueixen en senyals concrets que pots reconèixer al moment.

El patró comú del costat *agent*: el camí no és previsible, però les eines disponibles sí. L'agent decideix la **seqüència**; les eines (REST, BD, scripts, fitxers) continuen sent codi determinista.

### Tasques deterministes mal delegades

## Tasques deterministes mal delegades

Casos on el problema és clarament determinista i, malgrat tot, es delega a l'agent per defecte:

- **Validació o comptatge** → `grep -c`, scripts de validació, *linters*.

- **Migracions de dades o configuració** → scripts amb passos explícits, idempotents i reversibles.

### Per què guanya el determinista

## Per què guanya el determinista

Per què invertir cinc minuts a escriure un script — o un *one-liner*, o configurar un refactor de l'IDE — en lloc de delegar la tasca? Perquè aporta propietats que un agent estructuralment **no pot oferir**:

Tot plegat es resumeix així: **un script captura la solució; un agent reprodueix el procés**. Quan el procés és el mateix cada vegada, capturar-lo és sempre millor que reproduir-lo.

### I si la tasca és única?

## I si la tasca és única?

La reusabilitat és una raó forta per formalitzar, però **no és l'única**. Hi ha casos on una tasca determinista d'una sola vegada s'expressa millor com a comanda o script encara que no la tornis a executar mai més:

> **Per a problemes deterministes, el camí determinista (script, comanda, refactor) és el bo per defecte. L'agent guanya només quan la fricció de fer-ho deterministement és real — no per defecte.**

### I si la tasca demana judici?

## I si la tasca demana judici?

Hem dit que els problemes amb ambigüitat real són el cas legítim per a l'agent. Però *legítim* no vol dir *automàtic*. Hi ha casos on, fins i tot quan la tasca demana judici, la millor opció **no és l'agent — ets tu**:

El patró general: **l'agent és més ràpid implementant; tu ets insubstituïble decidint, sentint el sistema i construint criteri**. Quan la tasca toca aquestes tres dimensions, *fer-la tu mateix* no és lentitud — és la feina.

#### Productivitat vs aprenentatge

### Productivitat vs aprenentatge

Hi ha una tensió que val la pena nomenar explícitament: **productivitat vs aprenentatge**. L'agent gairebé sempre guanya en productivitat immediata — fa la feina més ràpid del que la faries tu. Però el cost d'aquella velocitat és el **criteri que no construeixes** mentre delegues. Cada decisió que passa pel model és una decisió que no has practicat — i el criteri només es construeix prenent-les tu, vivint amb les conseqüències, i veient què falla.

La regla pràctica: **demana't quina inversió estàs fent** cada vegada que decideixes delegar. Si el que guanyes és temps i el que perds és criteri que no necessites refrescar — és una bona inversió. Si el que guanyes és temps i el que perds és precisament el criteri que t'està faltant — has fet exactament el contrari del que necessites.

### L'agent escriu l'script

## L'agent escriu l'script

La decisió no sempre és "agent o script" — sovint és **"l'agent escriu el script"**. En lloc de demanar *"renombra totes les ocurrències de `foo` a `bar`"*, demana *"escriu-me la comanda `sed` que renombri totes les ocurrències de `foo` a `bar` als fitxers `.py`"*. Obtens el millor dels dos paradigmes:

Quan una exploració amb agent fa visible el camí, el següent pas natural és **convertir-lo en codi determinista** — no consolidar l'agent com a part permanent del flux.

### Donar eines fiables a l'agent

## Donar eines fiables a l'agent

Si saps com fer una tasca de manera determinista, no deixis que l'agent l'endevini estocàsticament — **dóna-li l'eina perquè la faci bé**.

Tot això implica que **decidir quines operacions exposar, amb quin contracte i a quina granularitat** és una decisió de disseny que determina el sostre del que l'agent pot fer de manera fiable. Aprendre a escriure scripts, validadors i transformacions deterministes no és una habilitat "pre-IA" que perdrà valor — és el fonament per treure el màxim d'un agent.

### Usar l'agent per no pensar

## Usar l'agent per no pensar

Tornem al tercer tipus de problema — el desconeixement temporal del domini. El cas perillós no és *"tasca determinista delegada a l'agent"* — és *"tasca que **semblava** ambigua perquè encara no havíem entès el problema"*. L'agent produeix una resposta raonable, i això elimina la pressió per fer la feina d'enginyeria de definir-lo.

La mitigació no és deixar de fer servir l'agent — és **fer servir l'agent per descobrir les regles, i llavors codificar-les**. Si una tasca s'ha resolt amb l'agent dues o tres vegades, ja saps prou per formalitzar-la.

### Heurística final

## Heurística final

Abans de delegar, una pausa breu: