Vibe coding: usos i límits

Doneu espai per crear

El CTO d’una empresa pot ajudar més persones a convertir els seus coneixements en idees de programari. Convideu-hi persones de finances, operacions, vendes i enginyeria. Proporcioneu-los temps, dades sintètiques, API de proves i suport.

Permeteu que explorin amb eines diferents dins d’uns límits clars per a la instal·lació, els comptes i les dades d’entrada permeses. Un creador d’aplicacions al navegador, un assistent de programació o un agent local poden ajudar a provar una idea. Triar una eina no dona permís per carregar informació de l’empresa ni per connectar un sistema real.

Publiqueu un procediment senzill per presentar un prototip útil a l’equip d’enginyeria o de plataforma. Qui l’ha creat aporta el problema, un exemple de flux de treball i el valor observat. No ha de convertir-se en l’equip de seguretat i operacions del servei.

Identifiqueu què necessiteu aprendre

El vibe coding sol començar amb una descripció del programari que voleu. Accepteu el codi generat i utilitzeu el resultat visible per orientar el canvi següent. El terme té diversos significats. En aquesta guia, la persona que dirigeix la feina no necessàriament entén cada decisió d’implementació.

Aquest mètode pot ajudar a aprendre. Una interfície senzilla pot mostrar que un procés d’aprovació té massa passos. Un script temporal pot ajudar a avaluar un format de fitxer. Un prototip dona a les persones un disseny concret per discutir. Podeu conservar aquest coneixement encara que descarteu el codi.

Primer, definiu una pregunta amb una resposta observable. Per exemple: «Un responsable d’equip pot entendre aquest procés d’aprovació?». Aquesta pregunta té un abast clar. Una petició de crear un sistema de despeses també inclou protecció de dades, control d’accés, operació i responsabilitats.

El prototip bancari de dimarts

Considereu un exemple fictici. Dimarts, una persona de finances utilitza Lovable per crear un tauler amb transaccions bancàries inventades. Agrupa les despeses i mostra les factures pendents de pagament. Ara l’equip pot discutir un flux de treball útil.

Algú proposa connectar-hi el compte bancari de l’empresa. Això canvia les conseqüències, encara que l’aplicació continuï etiquetada com a «prototip».

L’accés de lectura pot revelar saldos, historial de transaccions, noms de clients o referències de pagament, segons l’API. Si la connexió també permet fer pagaments, els errors poden moure diners reals. Confirmeu l’abast real dels permisos; una connexió bancària no sempre inclou accés als pagaments.

La demostració no acredita que un usuari només pugui veure els comptes als quals té accés autoritzat. Amagar un botó no fa complir un permís. OWASP explica com la falta de comprovacions de comptes o registres pot exposar les dades d’un altre usuari.

En les API de pagament, la idempotència significa que repetir una petició no repeteix l’efecte previst. Stripe documenta una implementació. Comproveu el comportament, els límits i les regles de reintent del proveïdor real. Revertir una versió de l’aplicació no desfà un pagament que el banc ja ha processat.

Aquest exemple no és una evidència d’un defecte de Lovable. Les directrius de seguretat de Lovable demanen protegir els secrets, comprovar al servidor, provar les polítiques de dades i mantenir una revisió continuada. Apliqueu el mateix nivell d’exigència a les evidències de qualsevol creador d’aplicacions, agent o aplicació escrita manualment.

Comproveu l’accés abans de connectar sistemes reals

Continueu provant el flux de treball amb dades sintètiques i comptes de proves. Abans de donar accés real, feu que els responsables del servei, de seguretat i de plataforma verifiquin l’aplicació i l’entorn on funciona.

Utilitzeu el flux de connexió aprovat pel banc o el proveïdor. Doneu accés només als comptes i permisos necessaris. Deseu les credencials privades en un sistema de secrets aprovat, fora dels prompts i del codi del navegador. Assigneu aprovacions i límits de pagament quan calgui fer pagaments. Verifiqueu com revocar l’accés, investigar fallades i respondre a activitats sospitoses.

Aquestes decisions han de precedir l’entrada de dades confidencials o credencials reals al sistema. Esperar una publicació formal en producció pot ser massa tard. Continueu amb els límits de dades i la infraestructura empresarial.

Definiu les responsabilitats abans d’ampliar l’ús

Un experiment amb dades inventades pot tenir una vida curta i pocs usuaris. Quan altres persones depenguin de l’aplicació, definiu les responsabilitats del seu ús.

1. Indiqueu qui n’és responsable.
2. Identifiqueu els usuaris i les dades permesos.
3. Definiu la resposta a una fallada.
4. Manteniu el codi font i la configuració en un repositori.
5. Verifiqueu que una altra persona pugui inspeccionar i reproduir el sistema.

No tots els scripts necessiten una plataforma empresarial. Un formatador personal sense dades sensibles necessita menys controls que una aplicació d’aprovació de pagaments. Avalueu les conseqüències d’un error. Comproveu si podeu detectar-lo i revertir-ne els efectes.

Abans d’ampliar el prototip, separeu el que heu après sobre el problema de les evidències sobre la implementació. Podeu conservar la interfície i substituir el codi intern. Podeu restringir-ne l’ús previst. També podeu mantenir el prototip com a experiment temporal.

Preveieu les vulnerabilitats després de la demostració

Una demostració reeixida pot amagar una mancança greu de manteniment. Pot aparèixer un nou avís de vulnerabilitat d’una dependència sense cap canvi al vostre codi. Una anàlisi feta en publicar descriu un únic moment.

Si l’aplicació continua en ús, algú ha de continuar detectant, avaluant i corregint vulnerabilitats. La correcció ha d’arribar a producció i superar la verificació. Un escàner sense aquest procés de resposta deixa l’exposició sense resoldre.

Comproveu què proporcionen l’eina i la configuració que feu servir realment. Més endavant, la gestió contínua de vulnerabilitats explica tot el procés, incloses les fallades d’anàlisi i les versions desplegades.

Faciliteu la revisió del canvi següent

Encarregueu a l’agent un canvi petit amb criteris d’acceptació explícits. Indiqueu quines accions pot fer. Inspeccioneu la comparació de canvis resultant. Feu comprovacions que puguin rebutjar una implementació incorrecta. Manteniu el desplegament com una decisió separada fins que les responsabilitats de publicació siguin clares.

El NIST Secure Software Development Framework descriu pràctiques més àmplies de desenvolupament segur. Feu-lo servir com a referència quan avalueu els controls que falten. No cal memoritzar el marc. Cal identificar les evidències que falten abans que el programari afecti altres persones.