Generar codi és fàcil. Entendre'l és la feina real.

La majoria hem publicat codi que no enteníem del tot. El vam generar, provar i desplegar. Va funcionar. És una admissió honesta, i si el teu equip treballa amb eines d'IA per programar, segurament et resulta familiar.

La velocitat a la qual ara produïm programari ha superat la nostra capacitat de comprendre'l. Però aquest patró no és nou.

Cada generació de la indústria del programari ha arribat a un punt en el qual la complexitat del sistema supera la capacitat de gestionar-lo. Als anys 60 va arribar la crisi del programari. Als 70, nous llenguatges. Als 80, la informàtica personal. Cada dècada va introduir eines que van resoldre el coll d'ampolla del moment i van habilitar el següent, encara més gran.

El que diferencia la IA no és el patró, sinó l'escala. Ara podem generar codi tan ràpid com podem descriure'l. La capacitat de producció és pràcticament il·limitada. La de comprensió, no.

Hi ha una distinció important que sovint es perd.

Fàcil vol dir poca fricció: descriús el que necessites i un agent d'IA ho produeix. Sense esforç significatiu.

Simple vol dir poc acoblament: cada part del sistema fa una sola cosa, no s'enreda innecessàriament amb les altres i es pot entendre i modificar sense haver de fer arqueologia sis mesos després.

El que és fàcil et permet afegir coses ràpidament. El que és simple et permet entendre —i canviar— el que has construït. Fer alguna cosa més fàcil és trivial. Fer alguna cosa simple requereix decisions de disseny deliberades.

La IA és el botó fàcil definitiu. Ha eliminat tanta fricció del camí ràpid que els equips rarament s'aturen a considerar l'altre.

Comença de manera innocent. L'equip demana a un agent d'IA que construeixi un sistema d'autenticació. Sembla net. Iterereren, afegeixen integracions, gestionen casos extrems. Cada petició és ràpida i el resultat sembla raonable.

Però a la vintena iteració, ningú dissenya ja: gestionen un context que ha crescut tant que les restriccions originals són difuses. Hi ha codi d'enfocaments abandonats que mai no es va netejar. Tests que es van «arreglar» fent-los passar en lloc de resoldre el problema de fons. Tres enfocaments diferents per al mateix problema coexistint al mateix sistema perquè l'equip anava canviant de direcció.

No hi ha fricció contra les males decisions. L'agent no assenyala una arquitectura deficient. El sistema simplement muta per satisfer l'última petició, acumulant complexitat oculta fins que qualsevol canvi resulta costós.

Qualsevol sistema en producció conté dos tipus de complexitat. La primera és intrínseca: la lògica de negoci real —autenticació, gestió de comandes, consistència de pagaments—. La segona és accidental: pegats, capes de compatibilitat, decisions que tenien sentit fa dos anys i no s'han revisat des de llavors.

Els enginyers amb experiència saben distingir-les. Saben quines parts del sistema reflecteixen requisits de negoci essencials i quines simplement són la manera com algú va resoldre alguna cosa sota pressió el 2022. Un agent d'IA no pot fer aquesta distinció. Cada patró existent li sembla igualment vàlid de preservar.

Això importa especialment quan el sistema necessita canviar. Quan els equips intenten evolucionar significativament un sistema construït d'aquesta manera, el cost no és només temps d'enginyeria: és el pes acumulat de decisions que ningú va entendre del tot des del principi. El sistema es resisteix al canvi no perquè el problema sigui difícil, sinó perquè la solució mai no es va comprendre realment.

L'enfocament que funciona és senzill, però requereix invertir el flux de treball habitual: primer invertir temps en comprendre i dissenyar, i després generar codi.

Mapeja el que existeix. Defineix amb claredat què ha de canviar i per què. Pren les decisions clau abans que comenci cap implementació. Llavors, amb un pla validat, deixa que la IA gestioni l'execució.

No es tracta d'anar més a poc a poc, sinó de fer que les parts ràpides siguin realment ràpides. Una tasca d'implementació ben especificada li pren a l'agent una fracció del temps, produeix resultats més predictibles i requereix molt menys revisió. El coll d'ampolla passa de «generar codi» a «prendre bones decisions», que és on hauria de ser.

El que no es pot delegar és el judici. La IA accelera l'execució. Les decisions que determinen si un sistema continuarà sent mantenible i extensible a llarg termini continuen sent humanes.

A mesura que generar codi es torna gairebé gratuït, la barrera d'entrada per construir programari baixa significativament. Cada cop més productes els construeixen equips sense experiència tècnica profunda —equips capaços de produir versions inicials convincents, però que encara no han topat amb els modes de fallada que apareixen a escala o amb el temps.

La diferència es manifesta quan el sistema necessita créixer, suportar càrrega real o recuperar-se d'una fallada inesperada. Els equips que no han mantingut sistemes en producció durant aquests moments no reconeixen quines decisions primerenques generen problemes greus més endavant. No detecten la complexitat excessiva mentre la estan generant.

Hi ha alguna cosa més subtil també. Cada vegada que un equip es salta la fase de disseny per mantenir la velocitat, no només està afegint codi que ningú entén del tot: està perdent la capacitat de reconèixer quan alguna cosa s'està tornant més difícil de gestionar del que hauria de ser. Detectar aquest senyal requereix entendre el teu propi sistema.

Per als líders tècnics, la implicació és pràctica: el valor de l'experiència en enginyeria no està a escriure codi més ràpid. Està a saber quines decisions et costaran car més endavant, i prendre-les deliberadament abans que el sistema les prengui per tu.

La pregunta no és si s'usarà IA per construir programari. Això ja està decidit. La pregunta és si els qui l'utilitzen continuaran entenent el que estan construint, i si les organitzacions que financen aquest programari sabran distingir la diferència.