Vibe coding per a pimes: què pots construir amb IA i què has de validar

El vibe coding permet explicar amb llenguatge natural què hauria de fer una aplicació i utilitzar una eina d’IA per generar-ne o modificar-ne el codi. Pot accelerar una primera versió, però no converteix automàticament un prototip en una aplicació preparada per a clients, dades reals o processos crítics.

Per a una pime, el seu valor és provar una idea concreta abans d’invertir en un desenvolupament complet. Per exemple:

• Una calculadora o un configurador senzill.

• Un panell intern per ordenar informació.

• Un formulari connectat amb un full de càlcul o una API.

• Una eina per classificar sol·licituds.

• Un prototip de portal per a clients o treballadors.

La pregunta útil no és només «ho puc crear amb IA?», sinó «què hauria de revisar per utilitzar-ho amb seguretat i mantenir-ho després?».

Com a context de proveïdor, Lovable va anunciar el 15 d'octubre de 2026 noves integracions de models i eines d'IA, amb exemples d'aplicacions de veu, consulta de fonts i classificació de sol·licituds. Són capacitats descrites pel fabricant, no una avaluació independent ni resultats provats per Picarol. La utilitat concreta depèn de la configuració, els permisos i les proves de cada aplicació.

Exemple il·lustratiu i reproduïble

Imaginem una pime que vol ordenar una llista de feines pendents. El prototip rep un arxiu amb cinc camps: data, tipus de client, servei, responsable i estat. Després agrupa les tasques per servei i genera un resum.

Una prova prudent seria:

1. Definir per escrit què ha de fer i què no ha de fer.

2. Crear vint registres ficticis, sense noms ni dades reals.

3. Indicar a l’eina les regles exactes de classificació.

4. Preparar resultats esperats per a diversos casos.

5. Provar camps buits, dades duplicades, dates incorrectes i arxius amb un format inesperat.

6. Comparar el resultat de l’aplicació amb el resultat esperat.

7. Demanar una revisió tècnica abans de connectar-la amb informació o sistemes reals.

Aquest exemple no representa un projecte executat per Picarol ni demostra que qualsevol eina el pugui resoldre sense ajustos. Serveix per mostrar com es pot convertir una idea genèrica en una prova comprovable.

Què cal revisar abans de posar-la en ús

1. Objectiu i límits

L’aplicació ha de resoldre una tasca clarament definida. Convé anotar quins usuaris tindrà, quines dades rebrà, quin resultat ha de produir i quins casos quedaran fora de la primera versió.

També cal definir què passa quan l’aplicació no entén una entrada o no pot completar una operació. Un error controlat és preferible a una resposta aparentment correcta que ningú revisa.

2. Dades i privacitat

Abans de carregar informació, cal comprovar quines dades necessita realment l’aplicació, on es processen, durant quant de temps es conserven i qui les pot consultar.

Durant les proves és preferible utilitzar dades fictícies o anonimitzades. Si l’aplicació ha de tractar dades personals, documentació confidencial, pagaments o informació sensible, cal revisar l’abast tècnic i les obligacions aplicables abans de posar-la en ús.

3. Usuaris i permisos

No tots els usuaris haurien de poder veure, modificar o esborrar el mateix. Cal provar l’inici i el tancament de sessió, la recuperació de l’accés i els permisos de cada perfil.

Els comptes tècnics i les integracions haurien de disposar únicament dels permisos necessaris per a la seva funció.

4. Claus i components externs

Les contrasenyes, les claus d’API i les credencials no han de quedar escrites en el codi visible ni enviar-se al navegador. També cal identificar les biblioteques, els serveis i els models externs utilitzats, perquè poden canviar, tenir costos o deixar de mantenir-se.

5. Proves

Com a mínim, convé verificar:

• El recorregut principal de principi a fi.

• Entrades buides, duplicades, massa llargues o incorrectes.

• Missatges d’error comprensibles.

• Diferents usuaris i permisos.

• Ús en mòbil i escriptori quan correspongui.

• Navegació amb teclat i llegibilitat bàsica.

• Integracions, correus i registres realment rebuts.

• Què passa si un servei extern deixa de respondre.

Veure un formulari o una pantalla acabada no demostra que tot el procés funcioni.

6. Seguretat

El codi generat s’ha de revisar com qualsevol altre programari. Cal validar les entrades, limitar les accions sensibles, protegir arxius i credencials, registrar les operacions rellevants i evitar que una instrucció introduïda per un usuari pugui executar accions no previstes.

La seguretat s’ha d’incorporar durant el desenvolupament, les proves, el desplegament i el manteniment, i no afegir-se únicament al final. Aquest enfocament coincideix amb el Secure Software Development Framework de NIST i amb la seva guia actual de pràctiques DevSecOps.

7. Publicació i recuperació

Abans de desplegar cal disposar d’una còpia recuperable, una manera de tornar a la versió anterior i una separació raonable entre proves i producció.

Després del desplegament s’ha de comprovar la versió pública real. Una compilació correcta o una vista prèvia no demostren per si soles que producció funcioni igual.

8. Manteniment

Tota aplicació necessita una persona responsable, documentació mínima i un criteri per corregir errors, revisar dependències i atendre canvis en serveis externs.

També convé decidir quines mètriques permetran saber si l’eina aporta valor: temps dedicat, errors detectats, tasques completades o incidències generades. Sense una mesura inicial i un període de comparació, no es pot afirmar que l’automatització hagi millorat el procés.

Del prototip a una aplicació mantenible

El vibe coding pot ser una manera ràpida d’explorar una idea. El salt important arriba quan aquesta idea s’ha d’integrar amb dades, usuaris i processos reals.

Si ja tens un prototip o una tasca que vols convertir en una eina fiable, Picarol Digital pot revisar-ne l'encaix mitjançant el servei existent de programació a mida. El primer pas és un diagnòstic per decidir què es pot reutilitzar, què s'ha de corregir i quin manteniment necessitarà abans d'utilitzar-ho al negoci.