Com programo amb IA: el meu flux real amb Claude Code

Programo amb IA cada dia. No com a ajuda puntual: com a part del flux.

Aquí tens com ho faig de debò, amb el que funciona i el que m'ha sortit malament.

El primer: escriure el context una vegada

L'error més car que vaig cometre al principi va ser explicar el projecte de nou a cada conversa.

Ara cada repositori meu té un fitxer CLAUDE.md a l'arrel. És un document que el model llegeix en començar i que conté el que un desenvolupador nou necessitaria el primer dia:

• Les ordres. Com s'arrenca, com es compila, com es comprova.
• L'arquitectura. Què hi ha a cada carpeta i per què.
• Les decisions que no es toquen. Al meu web, per exemple, hi ha una regla que diu que sempre es navega amb el Link que respecta l'idioma, mai amb un enllaç normal. Això va arreglar una errada de SEO que ja havia comès una vegada.
• Els paranys. Coses que semblen bé i trenquen el build.

El fitxer del meu web personal ocupa unes dues pàgines. Costa mitja hora escriure'l bé. S'amortitza a la segona sessió.

L'important no és que sigui llarg. És que contingui el que no es dedueix llegint el codi.

Com encarrego la feina

Un encàrrec mal fet dona codi que compila i no serveix. Un encàrrec ben fet és la meitat de la feina.

Jo ho faig en tres parts.

Què vull aconseguir, en resultat, no en passos. "Vull que la fitxa de projecte mostri la galeria al mòbil sense carregar les imatges grans" és millor que "afegeix un component de galeria".

On viu això, en fitxers concrets. Si li dic on ha de mirar, no s'inventa una estructura paral·lela.

Què no pot trencar. Aquí és on més hi guanyo. "No canviïs el marcatge de l'h1", "no afegeixis dependències noves", "això s'ha de continuar generant de manera estàtica en els quatre idiomes".

Aquesta tercera part és la que gairebé ningú no escriu. És la que evita el 80% dels desastres.

El que li dono i el que no

Després d'un any llarg fent això tinc una divisió bastant clara.

L'hi dono sencer:

• Traduir un component a un altre idioma o adaptar textos a quatre locales.
• Canvis repetitius en molts fitxers. Reanomenar, migrar una API, aplicar un patró nou en vint llocs.
• Escriure la primera versió d'una cosa que ja he fet abans: un formulari, una taula amb filtres, un endpoint CRUD.
• Llegir codi d'altres i explicar-me'l. Aquí és on més temps m'estalvia i menys risc hi ha.
• Tests i comprovacions que jo escriuria amb desgana.

No l'hi dono:

• Decidir l'arquitectura de dades. Com s'aïlla la informació d'una empresa de la d'una altra a Savia ho vaig decidir jo, en paper, abans d'escriure una línia.
• Res que toqui seguretat o permisos sense que jo ho revisi línia a línia.
• La part del disseny on hi ha criteri. Un model et dona una interfície correcta. La diferència entre correcta i bona la continues posant tu.

La regla que faig servir: si no sabria revisar el resultat, no ho delego. La IA no és un substitut d'entendre el que estàs fent. És un multiplicador del que ja entens.

El build és el jutge

Aquesta part la considero la més important de tot l'article.

El meu web no té tests. Té una cosa que a la pràctica funciona igual de bé: l'ordre de compilació genera de manera estàtica totes les pàgines en els quatre idiomes. Si falta una traducció, si un JSON està mal tancat, si una ruta no existeix, el build falla.

Així que la instrucció permanent és: no em diguis que està fet fins que el build passi.

Això canvia la feina del tot. Sense una comprovació automàtica, revisar el codi generat et costa més que haver-lo escrit. Amb ella, tu mires el resultat i la màquina s'encarrega del que és mecànic.

Escriure es va abaratir. Comprovar no. I ara hi ha molt més per comprovar.

Per això, quan començo un projecte nou, el primer que munto és la manera de verificar-lo. Abans que la primera funcionalitat.

Anar per parts

Un encàrrec gran dona resultats dolents. Sempre divideixo.

Un exemple real, la secció de blog d'aquest mateix web:

1. Llegir els fitxers de contingut i treure'n les metadades. Comprovar que surten els vuit articles.
2. La pàgina de llistat, sense disseny fi. Comprovar que es veu.
3. La pàgina d'article amb el markdown renderitzat.
4. Metadades, canonical i hreflang. Comprovar-ho a l'HTML generat.
5. Sitemap i dades estructurades.
6. Disseny.

Cada pas es revisa abans del següent. Si el pas 3 va sortir tort, ho arreglo allà. No després d'haver muntat sis capes a sobre.

Quan una cosa es torça molt, prefereixo començar la conversa de zero amb el context corregit abans que discutir. Insistir sobre una conversa llarga que ja va anar per mal camí gairebé mai no surt barat.

El que m'ha sortit malament

Per si serveix d'avís.

Acceptar codi que no entenia. Compilava, feia el que li vaig demanar, i dues setmanes després no sabia per què estava escrit així. Ara, si no puc explicar per què funciona, ho reescric fins que puc.

Deixar que reorganitzés carpetes pel seu compte. Un canvi que vaig demanar en un component va acabar tocant vuit fitxers. Tot correcte. Cap d'aquells vuit no era el que jo volia tocar. Des de llavors acoto l'abast per escrit.

Confiar en dependències suggerides. Un paquet que resol el problema pot estar sense mantenir des de fa tres anys. Això ho miro jo, sempre.

El que ha canviat de debò

No és que escrigui més codi. És que arribo a acabar coses que abans deixava a mitges.

La feina avorrida té un cost més gran que el temps que ocupa: és la que fa que deixis projectes sense acabar. Quan aquella part deixa de fer mal, acabes més.

L'altra cosa que ha canviat és què em diferencia. Escriure el codi ja no és el que escasseja. Saber què cal construir, per a qui i per què, sí.

Abans de substituir professions, la IA està substituint tasques. Val la pena saber quines són les teves.