Control i autonomia
- Els modes de treball: Chat, Plan i Autònom
- Qui pren les decisions
- Ownership del codi
- Execució aïllada i automatització
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
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.
Els noms no són una nomenclatura universal de producte; són una abstracció útil per descriure tres graus d’autonomia que gairebé totes les eines modernes exposen d’una manera o altra.
| Mode | Què fa l’agent | Quan usar-lo |
|---|---|---|
| Chat | Llegeix i explica. No toca res | Entendre codi, explorar opcions, aprendre |
| Plan | Proposa un pla. Espera la teva aprovació | Tasques complexes, codis que no coneixes bé |
| Autònom | Planifica i executa immediatament | Tasques rutinàries en codi ben testejat |
Regla pràctica: el mode autònom és apropiat quan es compleixen tres condicions alhora:
- Les decisions de disseny ja estan preses (patrons, estructura, convencions) — la IA no ha de fer judicis arquitecturals; si n’ha de fer, la probabilitat que el resultat divergeixi del que esperes és alta
- Saps descriure el resultat esperat amb precisió perquè la IA no hagi d’omplir buits d’especificació — si no pots, la tasca encara requereix decisions que no has pres
- La verificació del resultat és senzilla — idealment automatitzada (tests, linting) que detectarà errors sense intervenció
Si falta alguna, baixa el mode — o executa l’agent en un entorn aïllat on els errors quedin continguts (vegeu Execució aïllada (sandboxing)).
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
| Situació | Mode | Per què |
|---|---|---|
| Codi existent que no coneixes | Chat | Entén abans de tocar res; els efectes secundaris abans d’entendre són sempre incorrectes |
| Codi existent, familiar, pocs tests | Plan | Verifica el canvi manualment; la revisió humana és l’únic control |
| Decisió d’arquitectura (nou servei, nou patró) | Chat → Plan | Chat per alinear el disseny; Plan per verificar que la implementació encaixa |
| Refactoring d’un mòdul ben testejat | Plan | Fins i tot amb tests, un refactor és un canvi estructural — revisa el diff abans que s’apliqui |
| Feature rutinària en codi ben testejat | Autònom | Els tests detecten regressions; el patró ja està establert |
| Selecció de framework | Chat | Decisió arquitectural amb conseqüències que es composen; demana crítica, no confirmació |
| Projecte amb framework, decisions d’ecosistema fetes | Autònom | El framework resol les decisions estructurals; la feina és implementació dins d’un patró conegut |
| 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
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 utilitza models entrenats amb la capacitat FIM (Fill-In-the-Middle): el model rep el codi anterior i posterior al cursor i genera el fragment que hi encaixa. No és un model de xat que completa al final — és un model que literalment omple un buit. Funciona bé quan el codi que ve a continuació és altament previsible a partir del context: boilerplate, patrons repetitius dins de codi establert, crides a APIs conegudes, completar una funció on l’estructura ja és clara. En aquests casos, acceptar la suggerència estalvia temps sense cost cognitiu real — saps què havia de venir i la IA ho ha escrit per tu.
Convé ser cautelós — o desactivar-la — quan el codi requereix judici: lògica complexa, codi de seguretat (autenticació, criptografia, validació d’entrada), dominis que no domines. En aquests contextos, una suggerència incorrecta acceptada per reflex és més costosa que el temps que estalvia. Amb un agent, la delegació és conscient — tries un mode, escrius un prompt, revises el resultat. Amb la compleció inline, la delegació és implícita i contínua: el codi apareix i l’acceptes o no en una fracció de segon. La disciplina no consisteix a triar un mode sinó a mantenir l’atenció sobre el que acceptes.
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
Els tres modes pressuposen que ja saps què vols construir. Però les eines IA — tant assistents com agents — canvien què val la pena explorar.
Quan produir un esborrany costa minuts en lloc d’hores, intuïcions i millores marginals que abans no justificaven l’esforç es converteixen en experiments viables: prototipar una idea d’arquitectura abans de comprometre-t’hi, investigar una optimització de rendiment que semblava massa costosa, o simplement veure si una idea vaga té recorregut. Llancem l’eina, avaluem el resultat, i revertim si no val la pena — el cost de l’exploració és pràcticament zero.
Això amplia el ventall de projectes que existeixen. Feines que mai haurien entrat en un sprint — perquè el retorn no justificava el cost humà — passen a ser projectes laterals d’un parell de dies. El límit entre “val la pena” i “no val la pena” es desplaça.
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
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
La distinció fonamental és entre decisions de disseny i treball d’implementació:
- Patrons estructurals
- 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.
- 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.
- La IA implementa el cos de les funcions que compleixen aquell contracte.
- Consistència amb el codi existent
- El desenvolupador decideix quin fitxer o patró existent al projecte serveix de referència.
- La IA implementa el codi nou replicant aquell estil i estructura.
- Cobertura de tests
- El desenvolupador decideix quins casos cal cobrir i què valida cada test.
- La IA implementa el codi mecànic del test: setup, execució i assercions.
- Dependències externes
- El desenvolupador decideix quina biblioteca o servei extern utilitzar i per quins motius.
- La IA implementa la integració tècnica: configuració, crides i gestió d’errors.
Quan un desenvolupador demana “refactoritza el mòdul d’usuaris” sense més context, la IA triarà l’estructura. Pot ser genèricament raonable o pot entrar en conflicte amb com està organitzat el projecte. Ningú no s’adonarà fins que la inconsistència creï problemes.
Els bons desenvolupadors volen prendre decisions. La IA és un executor hàbil, no un arquitecte.
Hi ha un segon mode de fallada: la IA endevina massa. Els agents tendeixen a la sobreenginyeria — abstraccions innecessàries, generalització prematura, capes d’indireccions extres. Les dades d’entrenament de la IA estan esbiaixades cap a exemples de “bones pràctiques” escrits per a sistemes grans i contextos pedagògics que emfatitzen l’extensibilitat. Un agent amb una vista local del codi no pot jutjar si un factory pattern, una strategy interface, o una capa addicional d’abstracció estan justificats per la complexitat real del problema.
Vigila la complexitat que no serveix cap requeriment actual. La simplicitat és una decisió de disseny que l’agent no prendrà sol.
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
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.
Això vol dir que el gap de verificació és més gran allà on el desenvolupador està menys equipat per tancar-lo.
La implicació pràctica és directa: el nivell d’autonomia segur depèn tant de la qualitat de l’entorn com de la capacitat de verificar la sortida.
Si encara estàs construint criteri arquitectural, la teva manera d’usar la IA ha de posar més pes en la verificació i el suport:
| Àrea | El que fa un junior | El que fa un sènior |
|---|---|---|
| Decisions estructurals | No les prenguis en solitari. Escala-les a algú amb l’experiència necessària, o usa Chat com a consulta, no com a eina de decisió | Pren les decisions i llavors delega la implementació |
| Mode d’autonomia | Autònom només per implementació dins d’un patró que algú amb experiència ja ha establert i revisat | Autònom en codi ben testejat i ben entès |
| Establir patrons | Segueix els patrons existents; demana ajuda per entendre’ls | Estableix patrons nous; documenta’ls perquè altres els segueixin |
| Revisió de codi IA | Verifica, qüestiona, pregunta. Si no entens per què un canvi és correcte, no l’acceptis encara | Verifica amb judici arquitectural i coneixement del domini |
| Frameworks | Usa’ls i aprèn-los a fons: encapsulen decisions arquitecturals pre-fetes. És una posició professional legítima — però només si el coneixes prou per distingir el que segueix les convencions del framework del que només ho sembla | Escull-los, avalua’ls, decideix quan desviar-se de les seves convencions |
El rol del sènior també canvia. Quan un junior escriu codi a mà, la revisió detecta naturalment problemes d’implementació — que és on el junior comet més errors. Amb IA, la implementació sol ser neta; el que el junior no veu són les decisions estructurals. Això vol dir que la contribució més valuosa del sènior passa de revisar qualitat de codi a fer les decisions arquitecturals visibles i accessibles abans que el junior comenci a treballar: documentar patrons, explicar el “per què” de les convencions, i revisar la sortida de la IA buscant encaix estructural més que correcció. Com més ràpid produeix codi el junior, més necessita que el sènior ja hagi establert el marc de decisions que manté aquell codi coherent.
Conèixer un framework i tenir criteri arquitectural no són el mateix. Un framework és arquitectura cristal·litzada: decisions preses per altres, congelades en convencions. Aprendre’l a fons exposa el junior a patrons (separació de responsabilitats, injecció de dependències, pipeline de middleware), però de manera passiva: absorbeix el què sense guanyar el per què. És un prerequisit del criteri, no encara criteri.
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
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 és el símptoma d’aquesta ownership erosionada; aquí tractem com preservar-la.
Històricament, aquesta ownership es construïa pel simple fet d’haver escrit el codi — pensar-lo línia a línia generava el model mental com a subproducte. Amb IA, escriure deixa de ser el que construeix el model mental, i per tant cal construir-lo explícitament, en un altre moment del flux de treball.
Per què és distint del code review convencional. Una revisió que només valida conformitat (“sembla bé, passa els tests, no introdueix linter warnings”) no construeix model mental. Valida que el codi sembli correcte; no valida que tu l’entens. La IA genera codi que passa aquesta revisió superficial amb facilitat — és precisament el que fa perillosa la pràctica de genera → accepta → publica.
Senyals de pèrdua d’ownership:
- Ningú pot explicar un mòdul sense tornar-lo a llegir des de zero.
- Les sessions de debugging comencen amb “haig de descobrir què fa això” en lloc de “sé què fa això, falla al punt X”.
- Decisions arquitecturals al codi que ningú recorda haver pres.
- Quan un incident de producció toca un mòdul, el temps de resposta es multiplica perquè cap persona en té model mental viu.
- Les úniques persones que “entenen” el codi són les que el van generar amb IA — i el seu enteniment és superficial, construït durant l’aprovació i no durant l’escriptura.
Com preservar-lo:
- Revisa entenent, no només aprovant. Si no pots explicar per què un canvi és correcte amb les teves pròpies paraules, no l’has entès encara. Torna a la sessió, fes preguntes, llegeix línia per línia.
- Documenta el per què quan la IA proposa un patró. Els què queden al codi; els per què queden al cap de qui va llegir el prompt i la resposta. Si no els extreus (ADR, comentari curt, fitxer de context), es perden.
- 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ó
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.
El principi és senzill: com més autònoma és l’execució, més importa aïllar-la. Executar un agent en mode autònom sobre la teva còpia de treball principal és raonable si estàs mirant la pantalla; llançar-ne deu en paral·lel sense supervisió, no. Per a delegacions no supervisades — CI, scripts programats, subagents efímers, worktrees paral·lels — el sandbox passa de bona pràctica a requisit.
El detall pràctic (contenidors, worktrees, permisos, xarxa restringida, llistes de comandes permeses) viu a Execució aïllada (sandboxing) dins de Pràctiques de treball amb agents. L’important en aquest nivell de control és la decisió anterior: abans de delegar una tasca, pregunta’t on la faràs córrer, no només en quin mode.
Però controlar un agent no és només decidir en quin mode treballa ni en quin entorn corre. En moltes tasques, la millor decisió és no fer servir cap agent i resoldre el problema de manera determinista.