Itequia

La IA no elimina l’enginyeria de software, la fa més necessària que mai

La IA no elimina la ingeniería de software

Durant dècades, escriure codi va ser car, lent i especialitzat. Aquesta escassetat tenia una conseqüència directa: el codi era un actiu que calia cuidar, mantenir i documentar amb cura.

Avui, amb les eines d’IA generativa disponibles (com GitHub Copilot o Claude Code), generar codi és ràpid, barat i gairebé instantani. Això no és una millora incremental: és un canvi estructural en l’economia del software.

El codi passa de ser un actiu permanent a ser una representació temporal del coneixement del sistema. Alguna cosa que pots descartar i regenerar quan ho necessitis, igual que regéneres un informe o recompiles un binari.

El que és difícil ja no és escriure’l ràpid. És saber exactament què volem que faci.

El problema real: entendre el sistema, no escriure línies

Històricament, tot el coneixement sobre com havia de comportar-se un sistema quedava implícit dins del propi codi. Els requisits, els casos límit, els comportaments crítics… Tot estava “amagat” entre les funcions i les classes.

Amb la IA, això canvia radicalment. Si el codi ja no és la font de veritat, el repte passa a ser:

  • Definir amb precisió què ha de fer el sistema
  • Validar que realment ho fa
  • Entendre els comportaments en producció

Aquest és el nou problema central del desenvolupament de software, el problema de l’avaluació. I és, precisament, el tipus de treball que requereix més criteri humà, no menys.

Un paral·lelisme que ja vam viure: la infraestructura immutable

Aquest canvi no és tan nou com sembla. La indústria ja el va travessar amb DevOps i la infraestructura com a codi.

Quan vam passar de servidors “mascota” (els que es configuraven a mà, un per un, i que ningú s’atrevia a tocar) a infraestructura immutable i reproduïble, el principi va ser clar: no arreglis el que falla, substitueix-ho.

La IA aplica aquest mateix paradigma al codi. En molts casos, és més eficient regenerar que modificar. Això té implicacions profundes:

  • Menys manteniment artesanal i acumulació de deute tècnic
  • Més sistemes dissenyats per ser reproduïbles i consistents
  • Major focus en les especificacions i els criteris d’acceptació

Validació i observabilitat: del marge al centre

El codi generat per IA pot ser no determinista. Dos prompts similars poden produir implementacions diferents. Això no és un problema, és una característica que cal gestionar.

La conseqüència directa és que la validació en producció deixa de ser una fase final del desenvolupament per convertir-se en part del procés. Com es diu al sector: la producció és part del desenvolupament.

Això requereix invertir més en:

  • Tests automatitzats amb alta cobertura i bona granularitat
  • Observabilitat real: traces, mètriques, logs estructurats
  • Feedback loops curts que permetin detectar desviacions en temps real

I aquí hi ha una reflexió important: els humans no som bons validant de forma repetitiva i sistemàtica. Ens cansem, ens distreiem, cometem errors de consistència. Les màquines, en canvi, ho fan cada vegada millor. El futur de la validació és automatitzat, però algú ha de dissenyar aquest sistema de validació, i això requereix enginyeria sòlida.

El nou rol de l’enginyer de software

Si el valor ja no està en escriure codi, on és? Els enginyers que més valor aporten en un entorn amb IA són els que saben:

  • Definir especificacions clares: què ha de fer el sistema, en quines condicions, amb quines restriccions, etc.
  • Dissenyar l’arquitectura: les decisions estructurals que la IA no pot prendre per si sola.
  • Construir sistemes de validació: tests, evals, pipelines d’observabilitat, etc.
  • Interpretar comportaments reals: entendre per què el sistema es comporta d’una manera en producció i com millorar-lo.

El focus es desplaça de la producció de codi a la disciplina d’enginyeria. I aquesta disciplina és més exigent, no més fàcil.

La gran tesi: més rigor, no menys

Hi ha un corrent (l’anomenat vibe coding) que suggereix que amb IA podem construir software de forma més casual, més improvisada, sense tanta estructura. L’experiència en projectes reals apunta en direcció contrària.

Els sistemes que incorporen IA necessiten:

  • Més rigor en la definició de requisits i comportaments esperats.
  • Feedback loops més curts per detectar desviacions abans que escalen.
  • Millor enginyeria a la base, precisament perquè la velocitat de generació és major.

Sense disciplina, la IA produeix molts experiments i poc valor sostenible. Amb disciplina, multiplica la capacitat d’un equip de forma exponencial.

Què significa això per a la teva empresa

El software com a commodity és una realitat que s’accelera. Però el valor diferencial no desapareix: es desplaça.

Les organitzacions que guanyaran en aquest nou entorn seran les que inverteixin en:

  • Arquitectura i decisions tècniques de qualitat
  • Processos robustos de validació i aprenentatge continu
  • Equips amb disciplina d’enginyeria, no només amb capacitat de generar codi

A Itequia portem anys ajudant empreses a construir software que no només funciona avui, sinó que escala, es manté i evoluciona. La IA no canvia aquesta missió: la fa més rellevant.

T’ho mostrem en la nostra sèrie de webinars sobre desenvolupament amb IA: com desenvolupar software fins a 10 vegades més ràpid en projectes nous i com modernitzar o reconstruir sistemes heretats sense perdre funcionalitat.

Si vols explorar com incorporar aquestes pràctiques a la teva organització, contacta amb nosaltres.

PREGUNTES FREQÜENTS

Sempre és millor regenerar el codi que mantenir-lo?

No sempre. Regenerar té sentit quan l’especificació és clara i el component està acotat: allà refer-lo és més ràpid i net que pegatejar-lo. L’error no és regenerar un sistema poc documentat, sinó fer-ho a cegues: el primer és recuperar què fa i per què, i reconstruir a partir d’aquí sense perdre comportament. La clau no és triar entre regenerar o mantenir, sinó tenir l’especificació prou explícita com per regenerar amb seguretat.

Si el codi és desechable, on queda el coneixement del sistema?

En l’especificació, els criteris d’acceptació i la documentació del comportament esperat. Si el codi es pot regenerar, el que no et pots permetre perdre és la definició de què ha de fer el sistema i per què. Aquest coneixement passa a ser l’actiu que cal cuidar, no les línies de codi.

Generar codi més ràpid no accelera també el deute tècnic?

Si es genera sense criteri, sí: el deute creix igual de ràpid. La diferència la marca tractar el codi com alguna cosa regenerable, amb una especificació clara i una arquitectura neta al darrere, en lloc d’anar acumulant pedaços. El deute tècnic no el porta la IA, el porta generar sense especificació ni arquitectura.


Desenvolupament de software amb IA | Itequia AI Web