Tipus de projecte
Aquest capítol adapta la guia al context real del codi: brownfield, legacy, greenfield i projectes amb o sense framework no demanen el mateix nivell de control.
La mateixa infraestructura de control — decisions explícites, contractes, tests i CI/CD — no pesa igual en tots els entorns. Les pràctiques d’aquesta guia s’apliquen a qualsevol tasca, però la intensitat amb què les has d’exercir varia segons el punt de partida. Un projecte des de zero, un codi existent consolidat i un codi legacy demanen dosificacions diferents — i saltar-se aquesta adaptació és on moltes sessions amb IA descarrilen.
Treballar en codis existents (brownfield)
La majoria del temps de desenvolupador es passa en codi existent — les estimacions posen el manteniment i extensió al 60-80% de l’esforç total. Brownfield inclou qualsevol base de codi ja existent, des d’una de sana i ben coberta de tests fins a una d’antiga i fràgil. Legacy és un subcas concret: codi amb baixa cobertura de tests, convencions implícites o oblidades, dependències obsoletes i sovint sense els autors originals a l’equip. La distinció importa perquè cada cas demana un flux diferent.
El risc comú: la IA aplicarà patrons estadísticament comuns que poden no ser els d’aquest projecte. El resultat és codi que passa una revisió ràpida però viola una convenció implícita.
Brownfield en bon estat
Quan els tests cobreixen raonablement el mòdul i les convencions són discernibles llegint el codi, pots delegar aviat, però amb ordre:
- Situa’t al patró. Una passada curta de Chat per identificar el patró canònic del mòdul on viuràs. No demanes codi encara — només et fas una imatge de quina convenció has de replicar.
- Prepara el context de la sessió. Apunta la IA al fitxer exemple, carrega les convencions documentades, i explicita les regles de domini que no siguin òbvies als tipus o als tests.
- Delega amb abast acotat. Un prompt, una responsabilitat; diff revisable d’un cop. Si la tasca és gran, parteix-la en subtasques amb els seus propis prompts.
- Verifica contra els tests existents. Com que la cobertura és raonable, els tests són la primera xarxa de seguretat. Un test que es trenca en un lloc inesperat és un senyal que la IA ha tocat més del que tocava.
Aquest flux és segur només si algú de l’equip manté l’ownership del codi que la IA produeix — no n’hi ha prou que els tests passin. Un mòdul generat ràpidament pot passar a ser opac si ningú no l’entén en profunditat. Vegeu Control i autonomia.
Codis legacy
Un codi legacy és el pitjor cas: totes les dimensions estan al seu estat inicial alhora. A més de la manca de tests i de convencions documentades, hi ha sovint una dimensió addicional: l’equip actual no té ownership del codi. Ningú no el va escriure, ningú no pot validar les hipòtesis que la IA proposarà sobre el per què de les decisions originals. La IA és excel·lent arqueòloga — resumeix mòduls, tracca fluxos, proposa raons — però inventa justificacions amb la mateixa confiança amb què reporta les correctes, i no hi ha autor original per desmentir-les.
La diferència amb brownfield en bon estat és que no pots delegar fins que no has reconstruït tu mateix les xarxes de seguretat que allà ja existeixen. La seqüència importa:
- Entén abans de tocar — usa Chat per construir una imatge del mòdul. La IA pot hipotetitzar; tu valides contra el codi.
- Escriu tests de caracterització — captura el comportament actual com a xarxa de seguretat. No els dissenyis per validar què hauria de fer el codi, sinó què fa ara. Cada test és també un acte d’ownership: a partir d’aquí, l’equip es fa responsable que aquest comportament es mantingui.
- Decideix el patró objectiu — tu, no la IA. Si no hi ha patró establert, n’has de triar un.
- Llavors delega — amb tests i un patró clar, és segur donar feina a la IA.
Saltar-se qualsevol d’aquestes quatre passes converteix la IA en un accelerador de danys: produirà codi ràpid que reforça decisions que el codi original no volia prendre, però que la manca de xarxa de seguretat no permet detectar.
Dues precaucions addicionals per a legacy sense ownership:
- No deixis que la IA inventi el per què. Si et dona una justificació per una decisió original, tracta-la com a hipòtesi. En un ADR retrospectiu, marca-ho explícitament (“raó presumida, no verificada amb autor original”).
- Reconstrueix ownership gradualment. Cada cop que toques un mòdul, extreu el que aprens a artefactes durables (ADR, walkthrough commitat, entrada al fitxer de context). No intentis documentar tot el sistema abans de tocar res — ancora la documentació a la feina que estàs fent igualment.
Projectes nous (greenfield)
A diferència de brownfield en bon estat — on l’arquitectura ja existeix i la teva feina és respectar-la — un projecte des de zero no té patrons, i la càrrega d’especificació és màxima. Cada decisió que no prens explícitament, la IA la prendrà implícitament. El codi resultant semblarà raonable i passarà tests, però pot no reflectir el disseny que volies.
Què fer: avança l’especificació. Defineix els patrons arquitecturals, les convencions de noms, l’estructura de mòduls i la gestió d’errors abans d’escriure cap codi.
El risc específic de greenfield amb IA no és només arquitectural: és que l’equip mai arribi a desenvolupar ownership del codi, perquè tot ha estat generat i aprovat en lloc d’escrit i pensat. Un greenfield IA-first pot arribar a producció amb ningú que en conegui en profunditat el funcionament — un legacy recent nascut.
Si treballes amb framework, la càrrega d’especificació es redueix notablement — vegeu la subsecció següent.
Amb framework o sense
El tipus de projecte no és l’únic factor que canvia la càrrega d’especificació. També importa si treballes dins d’un framework o fora d’ell.
Què resol el framework per tu. Un framework és arquitectura cristal·litzada: convencions de nomenclatura, estructura de carpetes, patrons de cicle de vida, gestió d’errors, injecció de dependències. Això redueix la càrrega d’especificació — moltes decisions ja venen preses — i fa la sortida de la IA més previsible, perquè els defaults del framework coincideixen amb el que el model ha vist milers de vegades durant l’entrenament. És una de les raons per les quals el mode autònom és segur més aviat en projectes amb framework (vegeu Control i autonomia).
Els riscos específics.
- Desviacions intencionals. Si el teu projecte s’aparta d’alguna convenció del framework — per raons de rendiment, integració legacy, decisió de domini — la IA aplicarà el default silenciosament. Has de dir-ho explícitament, cada sessió si cal, o documentar-ho al fitxer de context del projecte.
- “Sembla framework, però no ho és”. La IA pot generar codi que visualment imita les convencions del framework però no les segueix bé (hooks mal ordenats a React, migracions no idempotents a Django, middleware fora del pipeline esperat). Detectar-ho requereix conèixer el framework prou bé — un lector superficial ho deixarà passar (vegeu Control i autonomia).
- Variants d’ecosistema. El framework no fixa tot. React no decideix SSR vs SPA; Django no decideix REST vs GraphQL; Rails no decideix com gestiones l’estat del client. Aquestes decisions són teves, i si no les expliques al prompt, la IA triarà pel model estadístic — no necessàriament el que necessites.
- Organització per sobre del framework. Com agrupes mòduls, com estructures els tests, com dividies els bounded contexts — tot això queda fora del framework i és on més fàcil divergeix la sortida de la IA del que vol el projecte.
Sense framework, la càrrega d’especificació és màxima: totes les decisions estructurals queden per tu. És on més val la pena invertir en infraestructura de context (ADRs, exemples canònics, fitxer d’instruccions) abans de delegar gaire.