A Ratatouille, el xef Gusteau creu que cuinar hauria d’estar a l’abast de tothom. Remy no n’està tan convençut: saber cuinar no vol dir necessàriament que algú hagi de poder entrar a la cuina sense més. El seu breu intercanvi captura una tensió que ara ens resulta familiar en el desenvolupament de programari.
Dona a algú un assistent de programació amb IA i podrà convertir una idea en una aplicació funcional. Un tauler de control. Un portal per a clients. Una automatització que elimini hores de feina repetitiva.
És una oportunitat extraordinària. Les persones que entenen un problema de negoci poden participar directament en la seva resolució, encara que mai no s’hagin considerat desenvolupadores.
Però una aplicació funcional és el principi d’una responsabilitat.
Algú encara ha de decidir on han d’anar les seves dades, qui hi pot accedir, com arriben els canvis a producció i què passa quan alguna cosa falla. Algú ha de garantir que encaixa amb els sistemes, les polítiques i les maneres de treballar de l’empresa.
Tothom pot preparar un plat. Un restaurant necessita tota una cuina al darrere.
Quan un experiment esdevé essencial
Considerem un escenari.
Una persona empleada vol una manera millor de fer el seguiment de les sol·licituds dels clients. Amb un assistent de programació amb IA, crea una aplicació petita. Té bon aspecte, estalvia temps i aviat comença a atreure alguns companys.
La connecta a dades reals de clients. Afegeix un procés en segon pla per mantenir-ho tot actualitzat. Per fer-la accessible, comparteix un enllaç.
Al cap de poques setmanes, l’equip en depèn.
Però l’aplicació s’executa al portàtil de la persona empleada. La seva integració utilitza una credencial personal. Ningú no ha acordat qui hi hauria de tenir accés, no s’ha provat la restauració d’una còpia de seguretat ni s’ha documentat com mantenir-la. Quan es tanca el portàtil, el procés en segon pla s’atura.
És possible que el codi funcioni exactament tal com estava previst. Però l’empresa continua tenint una dependència sense gestionar.
Res d’això requereix una intenció maliciosa ni una eina de programació incompetent. Cada pas pot semblar raonable quan l’objectiu immediat és simplement crear alguna cosa útil.
La dificultat és reconèixer quan un experiment s’ha convertit en un sistema del qual depenen altres persones.
La feina més enllà del codi
El desenvolupament de programari conté una gran quantitat de feina que gairebé no es veu en una demostració exitosa:
- Arquitectura i coherència. Aquesta funcionalitat hauria d’ampliar una aplicació existent? Quina base de dades, quin framework i quins components compartits hauria d’utilitzar? Com encaixa amb els sistemes i les convencions d’interfície existents de l’empresa?
- Integritat de les dades. Com pot canviar l’estructura de la base de dades sense malmetre els registres existents ni interrompre altres aplicacions? Si una sol·licitud es repeteix, crearà un pagament, un tiquet o un client duplicat?
- Gestió dels canvis. On es versiona el codi? Quina branca conté el canvi? Com es gestionen el treball simultani, els rebases, les revisions, les versions i la recuperació?
- Requisits i evidències. Què es va sol·licitar i què es considera un èxit? Pot algú seguir una incidència de Jira o un tiquet de suport des de la implementació, les proves, les evidències i la publicació? Tancar el tiquet vol dir que el problema de l’usuari s’ha resolt realment?
- Entorns i estacions de treball. Quins entorns d’execució, dependències, contenidors i serveis locals estan aprovats? Pot una altra persona reproduir la configuració? Les dades i les credencials de desenvolupament, proves, preproducció i producció estan separades adequadament?
- Operacions i responsabilitat. Qui supervisa l’aplicació, controla els costos, actualitza les dependències, respon davant les incidències i la manté quan la persona que l’ha creada ja no hi és?
També hi ha decisions sobre l’experiència que reben les persones. Dues aplicacions poden funcionar correctament i, alhora, presentar interfícies contradictòries, calcular de manera diferent la mateixa mètrica de negoci o mantenir versions en conflicte del mateix registre de client.
I les polítiques de l’empresa s’apliquen durant tot el procés. Una política d’ús de la IA pot determinar quines eines i comptes estan aprovats. Els requisits de privacitat influeixen en quines dades poden entrar en prompts, registres, captures de pantalla i evidències de proves. Les regles d’accés determinen quins sistemes pot llegir o modificar una persona —o un agent que actuï en nom seu—.
Aquestes responsabilitats es mantenen encara que la generació de codi millori.
De fet, podem defensar aquest argument sense debatre si la IA escriu bon codi o no: fins i tot si cada línia generada fos correcta, aquestes preguntes continuarien necessitant resposta.
Donar context a la IA
Codex i Claude Code poden ajudar amb bona part d’aquesta feina. Un agent pot inspeccionar una arquitectura existent, preparar un canvi a la base de dades, treballar en una branca, executar proves, documentar evidències i actualitzar una incidència.
Però necessita el context de l’empresa. Una sol·licitud per «crear un tauler de control de clients» no explica, per si sola, quin sistema de clients és l’autoritat de referència, quins camps són sensibles ni quina aprovació cal abans de publicar-lo.
El mateix s’aplica als desenvolupadors amb experiència que s’incorporen a una organització que no coneixen. La capacitat tècnica i el coneixement institucional són coses diferents. Totes dues són importants.
La part engrescadora és que aquest coneixement pot formar part de l’entorn de desenvolupament.
Codex permet compartir instruccions de projecte mitjançant AGENTS.md. Claude Code permet establir orientacions persistents mitjançant CLAUDE.md. Les skills, els plugins personalitzats i les integracions poden proporcionar fluxos de treball reutilitzables i accés als sistemes on es fa el seguiment de la feina.
En lloc d’explicar repetidament com desenvolupa programari l’empresa, els equips poden mantenir les orientacions al costat d’aquest programari: quins components cal reutilitzar, com provar un canvi, on han d’anar les evidències i què ha de passar abans de considerar completada una incidència.
Donar suport a les orientacions amb controls
Una instrucció que demani a un agent evitar les dades de producció ha d’estar avalada per credencials i permisos que en restringeixin l’accés. Un requisit d’executar proves ha d’estar recolzat per comprovacions abans de la publicació. Els entorns aprovats haurien de facilitar la reproducció de la configuració esperada.
La documentació de Claude Code distingeix explícitament entre les instruccions que guien el comportament i els permisos que controlen les accions. Aquesta distinció és essencial per establir una configuració empresarial fiable.
Les persones també necessiten entendre clarament les seves responsabilitats. La llibertat per experimentar pot ser àmplia, mentre que l’accés a informació sensible i l’autoritat per publicar canvis depenen del rol de la persona i de les conseqüències de l’aplicació.
Els enginyers amb experiència continuen sent centrals en aquest model. El seu criteri dona forma a l’arquitectura, estableix els controls, revisa els canvis importants i converteix les lliçons de projectes individuals en fonaments que altres poden reutilitzar.
Com ajuda Guanta
A Guanta, ajudem les empreses a crear aquest entorn al voltant del desenvolupament assistit per IA.
La feina comença per l’organització: els seus sistemes, dades, polítiques, equips i responsabilitats operatives. A partir d’aquí, reunim orientacions de desenvolupament, components reutilitzables, integracions, entorns controlats i fluxos de treball que connecten una sol·licitud de negoci amb un resultat verificable.
L’objectiu és convertir els estàndards de l’empresa en part de la manera de treballar, perquè les persones puguin dedicar més temps a resoldre problemes útils amb IA.
Així és com una participació més àmplia esdevé sostenible. Algú amb una bona idea hauria de poder explorar-la, construir sobre fonaments existents i seguir un camí clar cap a alguna cosa que l’organització pugui mantenir.
La promesa que «tothom pot programar» mereix fer-se realitat.
Dona’ls una cuina preparada per a això.