Com Desenvolupo amb IA

Context

Qui soc

Soc Victor Martin Garcia. Porto més de 25 anys construint software. He escrit codi, construït equips, donat classes a la universitat i liderat empreses. Avui el que més m’entusiasma és explorar com la IA està canviant la nostra manera de treballar com a desenvolupadors.

El que segueix és el meu procés real per desenvolupar amb IA. El que funciona, el que no, i el que he après construint productes reals d’aquesta manera.

Vibe coding vs. enginyeria amb agents

Hi ha una distinció que val la pena fer des del principi, perquè marca la diferència entre resultats mediocres i resultats professionals.

Vibe coding és llançar prompts a un model, acceptar el que retorna, i seguir endavant sense revisar-ho en profunditat. Funciona per a prototips ràpids i experiments personals. No funciona per a software que va a producció.

Enginyeria amb agents és una altra cosa. Aquí la IA executa tasques sota supervisió humana rigorosa. Tu defineixes la intenció, establexes estàndards de qualitat, revises cada resultat, i mantens el control arquitectònic del projecte. L’agent és un executor molt capaç, però tu continues sent el director.

Una nota per a developers junior

Si acceptes codi de l’agent sense entendre el que fa, no estàs aprenent. Estàs creant la il·lusió de competència. El codi funciona, el test passa, el PR es mergeja. Però si et pregunten per què funciona, no tens resposta.

La IA és una eina d’aprenentatge extraordinària si la fas servir activament. Demana-li que t’expliqui cada decisió. Pregunta-li per què va triar aquest patró i no un altre. Demana-li alternatives i compara-les. Fes servir l’agent com un mentor pacient que respon qualsevol pregunta sense jutjar-te.

El que no pots fer és fer-la servir com a drecera per saltar-te l’aprenentatge. Els fonaments importen. Algorismes, estructures de dades, patrons de disseny, com funciona la xarxa, com funcionen les bases de dades. Sense aquesta base, no pots avaluar el que l’agent produeix. I si no pots avaluar-ho, no pots dirigir-lo.

El canvi de rol

Treballar amb agents canvia fonamentalment el que fas com a desenvolupador. Passes de ser qui implementa a ser qui dirigeix. El teu dia a dia s’assembla menys a escriure codi i més a clarificar intenció, revisar arquitectura, i refinar qualitat.

Això no significa que deixis de pensar tècnicament. Al contrari. Necessites més criteri tècnic que mai, perquè estàs prenent decisions de disseny constantment i avaluant si el que l’agent produeix és correcte, eficient i mantenible.

La IA també t’ajuda en parts del cicle que abans ignoràvem o fèiem de mala gana: analitzar requisits, generar casos de test exhaustius, escriure documentació, analitzar logs de desplegament. No és només una eina d’implementació. És un assistent en tot el cicle de vida del software.

Sobre les eines

Ara mateix faig servir Claude Code com el meu assistent de codi IA principal. Però l’eina no és el important. Tot en aquest espai es mou tan ràpid que el que faig servir avui pot no ser el que faci servir el mes que ve.

No estic afiliat a Anthropic, OpenAI, ni a cap empresa de IA. Simplement faig servir el que millor em funciona ara i comparteixo el que vaig descobrint.

El procés

Preparació

El que configures una vegada i t’acompanya en cada projecte. Aquestes decisions defineixen com treballaràs amb els agents abans d’escriure la primera línia de codi.

1. Com pensar en els agents

Abans d’entrar en passos concrets, val la pena aturar-se un moment per entendre amb què estem treballant.

La teva feina és donar-los el context just i necessari perquè puguin prendre bones decisions amb la informació correcta. Ni massa (es perden), ni massa poc (inventen).

La bona notícia és que el codi ja conté molt context implícit. Els agents són molt bons navegant fitxers, llegint codi existent i extraient el que necessiten pel seu compte. Moltes vegades n’hi ha prou amb apuntar-los en la direcció correcta i deixar que ells descobreixin la resta.

2. Capturar tota la teva intenció

Un dels errors més comuns en començar amb agents és llançar-se a demanar-los codi directament. Abans d’escriure una sola línia, necessites tenir clar què vols construir. No a nivell de “vull una app de tasques”, sinó a nivell de decisions concretes: què fa exactament, què no fa, com es comporta en cada cas.

La bretxa entre el que tens al cap i el que l’agent entén és la font principal de problemes. Si alguna cosa és ambigua o està poc especificada, l’agent omplirà els buits amb les seves pròpies suposicions. De vegades encerta. Moltes vegades no.

La disciplina del spec-first. Abans de demanar-li res a l’agent, escriu un mini document de disseny. No cal que sigui formal. N’hi ha prou amb una descripció clara del problema, els requisits funcionals, les restriccions tècniques, i els casos límit que se t’acudeixin. Pensa-ho com “una cascada en 15 minuts”: defineixes el què abans de tocar el com. Aquest document es converteix en context que pots passar-li a l’agent juntament amb el teu prompt.

L’entrevista al revés. En comptes d’intentar anticipar cada possible dubte d’antuvi, pots demanar-li a l’agent que t’entrevisti.

És molt més fàcil respondre preguntes concretes (sobretot quan l’agent t’ofereix diverses opcions entre les quals triar) que pensar anticipadament en cada possible ambigüitat. L’agent treu a la llum dubtes que no sabies que existien, i acabes amb un enteniment compartit molt més precís.

El plan mode. Alguns agents, com Claude Code, tenen un mode on l’agent explora el codi, pensa el problema, i presenta un pla d’implementació detallat perquè el revisis abans que escrigui res. Llegeixes el pla, l’approves, demanes canvis, o el rebutges del tot. És com un code review però abans que el codi existeixi.

Les tres tècniques busquen el mateix: arribar a un enteniment compartit abans que comenci el treball real. El document de disseny funciona bé quan necessites pensar el problema tu primer. L’entrevista funciona quan encara estàs donant forma a la idea. El plan mode funciona quan la idea és clara però la implementació és complexa.

3. Triant les tecnologies

Abans d’escriure codi, hi ha una decisió que marca tot el que ve després: triar les tecnologies adequades. Això no va d’usar el més nou ni el més popular. Va de tenir el criteri tècnic per saber quina eina resol millor el problema concret que tens davant.

La IA et pot ajudar a implementar qualsevol cosa, però no prendrà aquesta decisió per tu. Si tries malament la base, tot el que construeixis a sobre serà més difícil del necessari. Dit això, si no tens l’experiència necessària en una àrea concreta, la pròpia IA és un bon punt de partida. Pots preguntar-li, explorar opcions amb ella, demanar-li que compari alternatives. No substitueix el teu criteri, però t’ajuda a formar-lo.

Hi ha un factor que abans no existia: convé triar tecnologies prou conegudes i mainstream perquè els agents de IA les manegin amb fluïdesa. Si fas servir alguna cosa molt de nínxol o molt nova, la IA tropeçarà més, inventarà coses, i t’alentirà en comptes d’ajudar-te.

4. El fitxer AGENTS.md

Cada agent de IA que conec permet definir un fitxer de context que es carrega automàticament cada vegada que comença a treballar. En Claude Code es diu CLAUDE.md, en Cursor .cursorrules, en altres tindrà un altre nom. El nom més estès a la comunitat és AGENTS.md. El concepte és el mateix: un document que li dóna a l’agent el context mínim necessari per entendre el teu projecte i prendre bones decisions.

Una bona manera de pensar en aquest fitxer és preguntar-te: què li explicaries a un nou membre de l’equip el seu primer dia de feina?

Normalment li explicaries dues coses. Primer, com està muntat el projecte: un diagrama tècnic de les peces principals, com es connecten, quines tecnologies es fan servir, on viu cada cosa. Segon, els acords de l’equip: les regles explícites i implícites que tothom ha de conèixer per treballar bé junts. Quins processos seguim, quins estàndards de qualitat apliquem, en quin idioma escrivim els commits, com anomenem les coses, què està prohibit.

Això és exactament el que ha de contenir el teu fitxer d’agent. Ni més ni menys. Si el sobrecarregues amb massa detall, l’agent perd el focus. Si el deixes massa buit, prendrà decisions sense context i hauràs de corregir-lo constantment.

A més del fitxer base, pots (i has de) empaquetar context addicional en els teus prompts quan sigui rellevant: fragments de codi existent, documentació d’APIs que necessiti consumir, implementacions de referència, o exemples de com vas resoldre alguna cosa similar abans. Aquest context packing és el que diferencia un prompt mediocre d’un que produeix resultats excel·lents a la primera.

5. Mantenir els agents actualitzats

Cada LLM està entrenat amb dades fins a una data de tall concreta. A la pràctica, això significa que el coneixement de l’agent sobre frameworks i llibreries està congelat en el temps, sovint mesos enrere. Quan li demanes que escrigui codi, farà servir per defecte la versió que va veure per última vegada durant el seu entrenament. Això pot portar a APIs deprecades, patrons obsolets, o bugs subtils difícils de detectar.

La bona notícia és que els agents moderns poden buscar a internet. Si saben que el seu coneixement pot estar desactualitzat, poden buscar documentació actualitzada pel seu compte. La clau és fer-los conscients del problema perquè realment ho facin.

6. Tests, qualitat i el bucle de feedback

Quan un agent modifica codi, necessites una manera objectiva de saber si el que ha fet funciona o ho ha trencat. Sense tests automatitzats, aquesta verificació recau completament en tu, revisant manualment cada canvi. Això no escala. Els tests són el que et permet delegar amb seguretat.

Però els tests no són només per a tu. Són el mecanisme de feedback que el propi agent fa servir per corregir-se. L’agent escriu codi, executa els tests, veu què falla, i corregeix. Aquest cicle funciona sol si els tests existeixen i són fiables. Sense ells, l’agent no té manera de saber si el seu codi funciona més enllà que “compila sense errors”.

Defineix en el teu AGENTS.md quin tipus de tests esperes (unitaris, integració, e2e), quin framework fas servir, i quina cobertura mínima és acceptable. L’agent seguirà aquestes regles de manera consistent.

El mateix principi s’aplica a la resta d’estàndards de qualitat. Tot el que normalment posaries en un pre-commit hook entra aquí: linters, formatació de codi, checks de vulnerabilitats. La clau és entendre que aquests checks no són només barreres de qualitat. Són feedback automàtic que l’agent consumeix. Si un linter falla, l’agent corregeix el codi. Si un test no passa, l’arregla abans de continuar. Si l’anàlisi de seguretat detecta una vulnerabilitat, la resol.

El flux complet funciona així: l’agent escriu codi, els checks s’executen, si alguna cosa falla l’agent rep l’error i corregeix, i repeteix fins que tot passa. És un bucle tancat on els estàndards de qualitat actuen com a senyals que guien l’agent cap a la solució correcta.

# .pre-commit-config.yaml
repos:
  - repo: https://github.com/pre-commit/pre-commit-hooks
    rev: v4.6.0
    hooks:
      - id: trailing-whitespace
      - id: end-of-file-fixer
      - id: check-merge-conflict
  - repo: https://github.com/astral-sh/ruff-pre-commit
    rev: v0.7.0
    hooks:
      - id: ruff          # linter
      - id: ruff-format   # formatter
  - repo: local
    hooks:
      - id: tests
        name: run tests
        entry: pytest --tb=short -q
        language: system
        pass_filenames: false
        always_run: true

La relació entre el teu AGENTS.md i els estàndards de qualitat ha de ser explícita. En l’AGENTS.md defineixes les regles (“fes servir Ruff per a linting, pytest per a tests, cobertura mínima del 80%”). En els pre-commit hooks les fas executables. L’agent llegeix les regles i respecta els hooks. Les dues peces treballen juntes.

7. Skills

Els skills són eines o interaccions que defineixes perquè l’agent les tingui sempre disponibles i les faci servir de manera consistent. En lloc d’explicar-li cada vegada com vols que faci alguna cosa, ho defineixes una vegada i a partir d’aquí ho fa sempre igual.

# /commit skill
Quan et demani fer commit:
1. Executa els tests (`yarn test`)
2. Si passen, fes `git add` dels fitxers rellevants
3. Escriu un commit message en anglès, format conventional commits
4. Fes push a la branca actual
5. Si els tests fallen, corregeix-los abans de continuar

Aquests són els tres que jo faig servir constantment:

El dia a dia

El flux de treball que es repeteix cada vegada que et poses a construir alguna cosa amb agents.

1. El flux iteratiu de treball

Aquí és on molts principiants es frustren. Llancen un prompt llarg, esperen que l’agent retorni codi perfecte a la primera, i es decepcionen quan no és així.

El flux real és un bucle: prompt, revisió, correcció, refinament. Els primers resultats gairebé mai són perfectes, i això és completament normal. L’important és que cada iteració millora el resultat, i normalment convergeixes en alguna cosa bona en dos o tres cicles.

La clau és treballar amb talls verticals petits. En lloc de demanar “implementa tot el sistema d’autenticació”, demana primer el model d’usuari, després l’endpoint de registre, després el de login, després el middleware de sessió. Cada peça és prou petita perquè l’agent la faci bé, i prou concreta perquè puguis verificar-la ràpidament.

2. Commits granulars com a punts de desament

Tracta cada commit com un punt de desament en un videojoc. Quan l’agent completa una tasca petita i els tests passen, fes commit. Si la següent tasca surt malament, pots tornar a l’últim punt estable amb un simple git checkout.

Aquest hàbit és més important del que sembla. Els agents de vegades es desvien del camí correcte: comencen a refactoritzar coses que no els has demanat, canvien la signatura de funcions existents, o introdueixen abstraccions innecessàries. Si has anat fent commits freqüents, el dany es limita a l’últim pas. Si portes una hora sense fer commit, pots perdre tot aquest progrés.

Una bona regla: un commit per cada tasca completada. No acumulis canvis. El cost de fer commit és pràcticament zero. El cost de perdre feina no ho és.

3. Mai mergeges codi que no entenguis

El codi que produeix l’agent és responsabilitat teva. Si arriba a producció i falla, no pots dir “és que ho va fer la IA”. Tu signes cada merge. Tu respons per cada línia.

A la pràctica això significa: si llegeixes codi de l’agent i alguna cosa et sembla confosa o innecessàriament complexa, no ho acceptis. Demana-li que t’ho expliqui. Si l’explicació no et convenç, demana-li que ho reescrigui de manera més clara. Si continua sense convèncer-te, rebutja-ho i escriu-ho tu.

Això s’aplica especialment als patrons que l’agent introdueix sense que li ho hagis demanat. Si veus una abstracció que no entens per què existeix, pregunta. Si veus un patró de disseny que et sembla excessiu per al problema, simplifica. El teu criteri mana.

4. Verificar la sortida de l’agent

Els agents inventen coses. És un comportament conegut que s’anomena al·lucinació, i convé entendre’l bé per saber detectar-lo.

Les al·lucinacions més perilloses no són els errors obvis que trenquen la compilació. Són les subtils: l’agent fa servir una API que sembla correcta però no existeix en la versió que estàs usant. Crida un mètode amb la signatura correcta de la versió anterior. Importa un paquet que va existir una vegada però ja està deprecat. Tot compila, els tipus quadren, i l’error només apareix en runtime.

Com verificar:

• Tests. Són la teva primera línia de defensa. Si el codi de l’agent no passa els tests, hi ha un problema clar.
• Revisió manual. Llegeix el codi com ho faries en un code review d’un company. Especialment les importacions, les crides a APIs externes, i la lògica de negoci.
• Revisió creuada amb un altre model. Pots fer servir un model diferent per revisar el codi generat pel primer. Cada model té biaixos diferents, i un segon parell d’ulls (encara que sigui artificial) atrapa errors que el primer no veu.
• Execució real. Quan és possible, executa el codi i prova’l manualment. Els tests cobreixen els casos que has anticipat. L’execució real cobreix els que no.

5. Gestió de context i mode multiagent

Les converses llargues amb un agent degraden la qualitat de les seves respostes. A mesura que la finestra de context s’omple, l’agent comença a “oblidar” decisions anteriors, a contradir-se, i a perdre el fil dels detalls. Aquest fenomen s’anomena context drift i és una de les raons principals per les quals el treball amb agents es complica en tasques grans.

La solució més senzilla: comença converses noves per a cada nova funcionalitat. No intentis fer-ho tot en una sola sessió marató. Cada conversa nova arrenca amb la finestra de context neta i l’agent opera a la seva màxima capacitat.

La solució més potent: mode multiagent. Algunes eines ho suporten de manera nativa. En Claude Code, per exemple, pots llançar i coordinar múltiples agents treballant sobre un pla compartit.

La millor manera de pensar-hi és com liderar el teu propi equip. Defineixes l’objectiu, el descomponents en rols, i assignes a cada agent una part de la feina. Un s’encarrega del backend, un altre del frontend, un tercer escriu tests. Treballen simultàniament, i tu coordines des de dalt.

L’avantatge obvi és la velocitat. Però l’avantatge real és que cada subagent rep una porció més petita i enfocada del problema. Poden anar molt més a fons en la seva tasca específica sense topar amb els límits de context. És la mateixa raó per la qual els equips humans funcionen millor quan cada persona és propietària d’una peça clara en lloc que tothom intenti mantenir la imatge completa al cap.

No has de fer servir exactament aquests rols. L’important és que definir responsabilitats clares des del principi li dóna a cada agent una missió ben delimitada. Reflecteix com opera un equip real, i els agents entenen aquests rols de manera natural.

6. Quan NO fer servir IA

La IA no és la resposta per a tot. Reconèixer els seus límits t’estalvia temps i frustracions.

• Codi de seguretat crítica. Criptografia, autenticació personalitzada, validació de tokens. Els errors aquí tenen conseqüències greus i els agents no tenen el context complet del teu model d’amenaces.
• Legacy fortament acoblat. Si el codi té dependències implícites per tot arreu i canviar una línia trenca tres mòduls, l’agent necessitarà més context del que li pots donar. De vegades és més ràpid fer-ho a mà.
• Hot paths de rendiment. Quan cada microsegon importa, necessites perfilar, mesurar, i optimitzar amb dades reals. L’agent pot suggerir optimitzacions genèriques, però les optimitzacions que importen de veritat requereixen context d’execució que l’agent no té.
• Recerca exploratòria. Quan ni tu saps exactament què vols construir i necessites experimentar amb idees a mig formar, la conversa amb l’agent pot ser més lenta que pensar amb llapis i paper.

Riscos i desafiaments

Recorda: això no és màgia. Treballar amb IA té riscos reals que convé conèixer abans que et trobin a tu.

Relacionats amb l’equip

Inherents a la IA

Tancament

Si hagués de resumir tot això en poques línies, seria això:

1. Entén amb què estàs treballant. No és vibe coding. És enginyeria amb agents: tu dirigeixes, la IA executa.
2. Prepara el terreny abans d’escriure codi. Intenció clara, tecnologies ben triades, AGENTS.md, estàndards de qualitat automatitzats.
3. Treballa en talls petits. Prompt, revisió, correcció, commit. Repeteix.
4. Mai mergeges el que no entenguis. Tu signes cada línia. Verifica, pregunta, rebutja si cal.
5. Gestiona el context. Converses noves, mode multiagent per a tasques grans, i sap quan la IA no és l’eina correcta.

El desenvolupament amb IA no és màgia. És un ofici nou que requereix pràctica, criteri, i disciplina. Les eines canvien cada mes, però aquests principis es mantenen.

Lectures recomanades

Si vols aprofundir en aquests temes, aquests són alguns recursos que m’han resultat útils:

• Build an AI-Native Engineering Team (OpenAI). Guia completa sobre com estructurar equips d’enginyeria al voltant d’agents de codi.
• How Claude Code is Built (Pragmatic Engineer). Com Anthropic construeix la seva pròpia eina de desenvolupament amb IA, des de dins.
• My LLM Coding Workflow Going Into 2026 (Addy Osmani). Flux de treball pràctic d’un dels enginyers més influents de l’ecosistema web.
• Claude Code: Best Practices (Anthropic). Documentació oficial amb patrons i bones pràctiques.

Si tens preguntes sobre algun punt concret, pots contactar-me directament.