Introducció
Últimament, YouTube sembla una desfilada de gurús del codi ensenyant com programar sense tocar el teclat. Tothom parla del vibe coding, aquest estil de desenvolupament on tu poses el context, et poses còmode, i l’IA pica codi per tu. Bé, això si tens sort i no et planta un microservei de trenta fitxers per fer una cosa que podries resoldre amb dues línies de Bash.
Però reconec que la proposta es cridanera: treballes des d’un IDE (Cursor, Windsurf…), escrius quatre indicacions i el model (qualsevol dels LLM’s principals) s’encarrega d’escriure, executar, revisar, tornar a provar, etc. Mitjançant la conversa amb el model pots anar refinant el codi (o si el model no s’ensurt pots canviar-lo tu mateix) i amb una mica de disciplina i documentació, pot fer coses sorprenents o si més no, força decents. A continuació explico la meva experiència, que va començar com un projecte petit i va acabar… bé, no ha acabat encara.
Projecte minúscul (Primeres proves)
Vaig començar per una idea senzilla: un petit programa en que em resumís els missatges de grups de WhatsApp configurats i me’ls enviés per correu a una hora concreta. Volia evitar distraccions durant el dia però no perdre el fil. I el resultat? Tot el projecte perfectament estructurat en fitxers, funcional a la primera i sense escriure un sola línia de codi. Jo només vaig mirar, provar, i flipar. Així de clar.
Projecte petit (posem-nos seriosos)
El projecte funcionava però estava pensat per programadors. Les preferències es tenien que escriure en un fitxer JSON i l’arquitectura no era escalable. Ni tant sols ho podia compartir amb amics i família perquè haurien de venir a casa a vincular el compte de WhatsApp a l’ordinador.
Com que el primer va anar tan fi, vaig pensar: “i si això ho escalo a una plataforma SaaS? Qui sap si inclús en podria treure uns dinerons” El model va començar a fer arquitectura gairebé sense preguntar. Sense validar res, per a be i per a mal.
Aquí vaig trobar a faltar un agent que pregunti abans de construir, i un altre que programi un cop tens el full de ruta clar. De fet potser va ser culpa meva, que no li havia facilitat les instruccions suficientment concises ni li havia detallat els fluxos.
Amb el pas de les hores i els dies (si, s’ha allargat molt més del previst), i mentre el projecte anava creixent en desordre i vaig començar a detectar els errors que havia comes.
Per començar, vaig veure que si no tens clar amb quines tecnologies treballaràs —i per a què les faràs servir—, el model decidirà per tu. I això no sempre és bo. Es indispensable que maximitzis l’us dels llenguatges i tecnologies que coneguis ja que si s’encalla al intentar arreglar quelcom puguis entrar-hi tu a rematar-ho en comptes de perdre temps intentant que ho faci el model. De tant en tant es més eficient “embrutar-te” les mans.
El gran avantatge d’aquests IDE’s es que el model, escriu, executa, detecta errors i torna a provar. Però no sempre sap quan aturar-se, i molt sovint es queda penjat esperant que passi una cosa que ja ha passat. Aquí cal estar al cas i saber interpretar què ha fallat per no perdre el fil. El propi model et va dient perquè creu que ha fallat. A vegades s’enfoca en arreglar el problema però no en la causa que el genera i li has d’indicar tu.
Crec que la millor estratègia es, després d’haver planificat amb cert detall les funcionalitats, l’arquitectura i els fluxos, anar per parts, amb una funcionalitat cada vegada. I aquí és on el vibe coding té sentit: no és un miracle, ni tant sols pots marxar i deixar l’ordinador desatès mentre programa, però si saps jugar-hi bé, et fa de parella de ball eficient.
També vaig començar a usar les funcionalitats pròpies de Cursor i Windsurf que permeten mantenir dues coses separades però essencials: un fitxer amb instruccions generals que el model sempre té en compte, i un altre amb la documentació viva del projecte. Aquest segon fitxer permet que el model sàpiga en tot moment les funcionalitats i que no s’oblidi de res.
Haig de seguir fent proves pero de models, el GPT-4.1 és el que més m’ha convençut per aquest tipus de feina. És menys impulsiu, pregunta abans de fer i t’explica què vol fer. Que sí, que pot semblar lent, però quan estàs intentant evitar catàstrofes arquitectòniques, això és un luxe.
Cost d’aquestes plataformes
Tot això, evidentment, no surt gratis. Tens versions bàsiques per jugar-hi una estona, però si vols fer un projecte amb cara i ulls prepara’t per pagar. Estem parlant de 20 € al mes pel pla personal en el qual et dona per uns 500 prompt’s (sempre pots pagar més diners per més crèdits) o 40 € o més per a entorns col·laboratius. Ara bé, si realment t’hi dediques, és una inversió més que raonable.
Conclusions
El projecte? Encara està a mitges. I sincerament, no sé si val més la pena arreglar-lo o llençar-lo i tornar a començar. Però el que tinc clar és que aquestes eines poden ser brutals si tu tens clar què vols fer i li saps detallar i guiar. Et pot salvar un projecte en el que tinguis deute tècnic però sempre que siguin coses concretes. No intentis fer un projecte que et sobrepassa molt tecnològicament perquè no sabràs com guiar el model.
Es un pas de gegant respecte a com es programa des de fa uns mesos/anys, on bàsicament li deies que volies fer a un LLM i ell et generar el codi i cada cop que fallava tenies que facilitar-li el codi actual, els logs, copiar i enganxar el codi corregit al teu editor i provar. A més a més aquesta metodologia dona un imatge molt més clara de tot el projecte al model i per tant es menys propens a les inconsistències
Amb el vibe coding, jo ho compararia amb un bon becari que acaba d’entrar i que te molt de talent però poca experiència. Te un potencial brutal però has li has d’anar demanant les tasques mica en mica, guiar-lo, estar pendent d’ell i si cal, ajudar-lo.
Ni de lluny substitueix la feina d’un programador, però fa el programador molt més eficient per tant podrà fer moltes més coses molt més ràpidament.