Reflexions finals

• Per què seguir escrivint codi a mà
• El coll d’ampolla es desplaça cap a l’arquitectura
• Precisió de llenguatge com a habilitat
• Dependència de proveïdors i cost de tokens
• El que no canvia

Aquest capítol tanca la guia amb tres idees de fons: per què encara val la pena escriure codi a mà, com la IA desplaça el coll d’ampolla cap a l’arquitectura i per què la precisió de llenguatge passa a ser una habilitat central.

Més enllà de la tècnica, treballar amb IA també canvia quines habilitats convé preservar i quines obliga a desenvolupar millor.

Per què seguir escrivint codi a mà

Amb eines tan potents, per què no delegar-ho tot?

Perquè l’acte d’escriure codi introdueix fricció productiva:

• Anomenar una funció et fa decidir què fa
• Definir un límit et fa decidir què pertany a cada costat
• Construir un flux de dades pas a pas et revela com “se sent” el sistema

Els desenvolupadors que deleguen tota la implementació i només revisen la sortida perden gradualment la intuïció que fa que la revisió sigui efectiva. Poden verificar que el codi compila i passa tests, però perden el sentit de si és correcte: si encaixa al sistema, si l’abstracció aguantarà, si l’enfocament serà mantenible.

Aquesta intuïció es construeix escrivint, no llegint. Un desenvolupador que periòdicament escriu codi a mà — especialment en àrees arquitecturalment significatives o desconegudes — manté el judici que fa que la delegació sigui segura.

La IA t’accelera. Però no pot substituir l’enteniment que només s’obté fent les coses tu mateix.

Escrit d’una altra manera: l’acte d’escriure és també l’acte pel qual es construïa tradicionalment l’ownership del codi. Quan delegues tota l’escriptura, aquesta ownership s’ha de construir explícitament — i si no ho fas, s’erosiona sense avís.

El coll d’ampolla es desplaça cap a l’arquitectura

Abans de la IA, la primera barrera d’un desenvolupador nou era fer que el codi funcionés: sintaxi, APIs, debugging, fer que compili. Això era lent, i la lentitud ensenyava. L’arquitectura venia després, quan implementar ja no era el problema.

La IA elimina gran part d’aquesta primera barrera. Un junior amb un agent pot produir codi funcional des del primer dia. Però el que queda — decidir on va el límit entre mòduls, quin patró seguir, quina interfície exposar — no ha canviat de dificultat. Simplement arriba abans.

I arriba d’una manera menys visible. Abans, un junior sense criteri arquitectural produïa codi lent i maldestre — el problema era obvi. Ara, el mateix junior produeix codi net que sembla professional però que posa un repository pattern on no calia, o crea un servei amb una interfície que no encaixa amb la resta del projecte. El problema existeix igual, però l’aparença del codi ja no el delata.

Cap drecera elimina aquesta barrera — només la desplaça. Els problemes que abans s’aprenien resolent-los a mà (per què aquest patró i no l’altre, per què aquesta frontera de mòdul, per què aquest contracte d’interfície) continuen existint; només arriben quan ja hi ha codi en producció que els travessa silenciosament. La velocitat dels primers mesos no compra criteri: només compra més codi al qual aplicar-lo quan finalment arribi.

Això reforça per què escriure codi a mà és especialment important per a qui està aprenent: la fase que la IA escurça és precisament la que construeix el criteri per jutjar si una estructura és correcta. I per la mateixa raó, la mentoria arquitectural — revisió de codi, explicar el “per què” dels patrons, ADRs — no pot esperar a quan el junior “ja domini la implementació”, perquè amb IA, ja està produint codi a velocitat de producció abans de tenir el criteri per saber si aquell codi hauria d’existir.

Precisió de llenguatge com a habilitat

Amb un col·lega humà, una instrucció vaga sovint activa una conversa: et demana què vols dir, comparteix context o empeny cap enrere. Amb la IA, massa sovint una instrucció vaga genera codi confidentment incorrecte — el model omple els buits en silenci amb el que és estadísticament probable, no amb el que necessites. El cost de la vaguetat és més alt: amb una persona, la imprecisió sovint es corregeix durant el diàleg; amb la IA, es converteix en codi que hauràs de depurar.

Això força el desenvolupador a fer la feina de clarificació abans del prompt, no durant. Has de saber què vols, anomenar-ho amb precisió, i anticipar on l’eina malinterpretarà. Això és, fonamentalment, una habilitat d’escriptura: convertir una intenció difusa en una especificació precisa.

El que fa interessant aquesta dinàmica és que l’habilitat sovint transfereix. Desenvolupadors que aprenen a comunicar-se amb precisió amb la IA acostumen a millorar també la comunicació amb humans: millors descripcions de PR, millors reports de bugs, millors especificacions. L’eina demanda una competència — llegir bé, escriure bé, pensar amb claredat — que la professió sempre ha necessitat però que rarament ha entrenat explícitament.

Dependència de proveïdors i cost de tokens

Hi ha un cost que no és cognitiu ni d’habilitat però que també creix amb l’ús: la dependència del proveïdor del model. Quan el flux de treball d’un equip depèn que un agent estigui disponible, una interrupció del proveïdor deixa l’equip parat. Feina que abans es feia amb un editor i un terminal passa a requerir una subscripció activa a una API que no controles, i una connectivitat que no garanteixes.

A diferència del cost d’un empleat — que és estable i previsible —, el cost en tokens és fluctuant per disseny: cada versió nova d’un model pot consumir-ne més per la mateixa feina, i els canvis de preus, capacitats o quotes són unilaterals. Equips que han fet de l’agent el seu camí per defecte no només paguen aquest cost; també han perdut la capacitat de produir el mateix sense ell.

Aquesta dependència no és el mateix que l’atròfia d’habilitat, però hi té una relació directa: com menys es practica la feina sense l’agent, més car i més arriscat es torna haver-la de fer sense. La mitigació és la mateixa que per al criteri — mantenir un nivell d’ús que preservi la capacitat de treballar sense l’eina quan calgui, i no fer-la l’únic camí. Models locals, eines deterministes ben mantingudes i la pràctica conscient d’escriure codi a mà són les tres palanques que mantenen oberta aquesta sortida.

El que no canvia

Les eines evolucionen ràpidament: formats de configuració, comportaments del model, fluxos de treball. Una inversió en afinar el fitxer d’instruccions o dominar les opcions d’un agent concret pot quedar obsoleta a la propera versió. Hi ha un risc real d’optimitzar el que caduca.

El que no caduca és la part humana de la col·laboració:

• Parla amb claredat. Instruccions vagues produeixen resultats vagues.
• Sap el que vols. Si no ho pots articular, l’agent omplirà els buits per tu.
• Ves al gra. Context irrellevant dilueix el que importa.
• Dona tot el context necessari. Però no més.
• Escriu bon feedback. Quan la sortida no és bona, un feedback precís sobre per què — no un “no, torna-ho a intentar” — és el que corregeix el rumb.
• Itera. El primer resultat rarament és el definitiu; el valor ve dels cicles curts de revisió.

Aquestes habilitats no depenen de cap eina concreta i transfereixen a qualsevol col·laboració — amb un agent nou, amb un model millor, amb un company humà. La resta és configuració.