Has fet l'MVP amb Claude Code. Producció és la part que la demo es va saltar

Aquesta setmana ens va escriure un fundador amb una frase que espero llegir moltes més vegades: «Estem desenvolupant un MVP per a la nostra startup, l'hem fet amb Claude Code i creiem que no el podrem fer servir en producció.» L'MVP funciona. Els usuaris el recorren. Els inversors l'han vist. I qui l'ha construït ja sap que no aguantarà.

Fa bé de dubtar-ne, i crec que s'equivoca en el motiu. Ho dic des del seient que revisa aquestes bases de codi: a Conectia fem servir Claude Code, Cursor i agents de revisió dins del nostre propi arnès d'enginyeria, i hem lliurat productes regulats d'identitat i pagaments amb agents al circuit. Aquest no és un article contra construir amb IA. És un article sobre el que la demo deixa fora.

El codi gairebé mai no és el problema. El que falta és el sistema que l'envolta. Un MVP fet a cop de prompt és una casa que ja té parets i teulada, i ni instal·lació elèctrica, ni fontaneria, ni llicència. Ningú no va muntar res d'això perquè ningú no ho va demanar, i l'agent que va aixecar les parets fa exactament el que li demanen.

El «vibe coding» ha produït els prototips més ràpids de la història, i els més prims

Andrej Karpathy va posar nom a la pràctica el febrer de 2025: descriu, accepta, executa, enganxa l'error de tornada, repeteix, i «oblida't que el codi existeix». Al novembre, Collins va triar vibe coding com a paraula de l'any. Entre una data i l'altra, les eines van millorar prou perquè un fundador sense perfil tècnic arribi avui a un producte que funciona en un cap de setmana. És un canvi real i no el canviaria pel d'abans.

El que la velocitat amaga és on ha anat el temps. Dues mesures del 2025 ho delimiten. Veracode va provar codi generat per més de cent models i va trobar que el 45 % de les mostres suspenia les proves de seguretat; en Java suspenia el 72 %, i en el 86 % dels casos rellevants hi faltava la defensa contra cross-site scripting. Els models escrivien codi que compilava i corria; no escrivien codi que es defensés. Aquell mateix estiu, METR va fer un assaig aleatoritzat amb desenvolupadors experimentats de codi obert i va mesurar que eren un 19 % més lents amb eines d'IA mentre creien anar un 20 % més ràpid. La distància entre la velocitat que se sent i la que es mesura és exactament la que nota un fundador quan l'MVP funciona i tot i això no pot sortir.

On es trenca de debò un MVP fet amb IA

He llegit prou d'aquests repositoris per saber-me la llista per endavant. Res no és exòtic; tot és feina que el prompt no va demanar mai.

• Una autorització que és interfície, no regla. L'app amaga el botó d'administrador; l'API serveix les dades d'administrador a qui les demani. El maig de 2025 un investigador va escanejar 1.645 aplicacions fetes amb Lovable i va trobar que 170 exposaven dades d'usuaris per no tenir seguretat a nivell de fila a Supabase. Les aplicacions no estaven trencades. Estaven obertes.
• Secrets dins del repositori. Claus d'API confirmades a git perquè l'agent les necessitava per executar, i després pujades a un GitHub públic.
• Cap mur entre entorns. Una base de dades, unes credencials i un agent amb permís d'escriptura a sobre. Així va ser com l'agent de Replit va esborrar una base de dades de producció el juliol de 2025 enmig d'una prova, després de rebre l'ordre de no tocar res.
• Un model de dades amb la forma de les converses, no del negoci. Cada funcionalitat hi va afegir la seva taula; res no migra; l'esquema és el que va deixar l'última xerrada.
• Zero proves als camins que mouen diners o dades. Pagament, alta, permisos. Si hi ha alguna prova, comprova el camí feliç que l'agent va fer servir per verificar-se a si mateix.
• Sense observabilitat i sense sostre de despesa. Si el producte crida un LLM, ningú no veu què costa una petició i res no impedeix que un bucle corri tota la nit.
• Dependències sense fixar i un desplegament que només funciona des del portàtil del fundador.

Cada punt són un o dos dies de feina sènior. El fundador que ens va escriure veu la pila sense poder-la anomenar, i per això «no pot anar a producció» li sona a veredicte sobre tota la base de codi. És un veredicte sobre set peces que falten.

L'objecció més forta, i té raó: l'MVP ja ha fet la seva feina

Algú dirà que el correcte és llençar-lo i refer-lo «bé». He vist aquest consell cremar dotze mesos de caixa més d'una vegada, molt abans que la IA entrés en escena. Joel Spolsky va dir de la reescriptura completa que era el pitjor error estratègic que pot cometre una empresa de software, l'any 2000, i el raonament no ha envellit: el codi vell l'han provat usuaris reals i el nou no.

Un MVP fet amb IA ja ha fet la part cara. Ha demostrat que algú vol el producte, ha fixat el vocabulari del domini i ha deixat una referència que funciona de cada pantalla i cada flux. Això és una especificació escrita en codi, i val més que la presentació que va substituir. La interfície sol sobreviure. Els fluxos sobreviuen. El model de dades sobreviu com a documentació del que el negoci necessita, encara que les taules en si no ho facin.

L'MVP no és l'error. L'error és tractar-lo com el sistema de producció.

Aquesta pel·lícula ja l'hem vist, amb un altre repartiment

El 2012 el fundador arribava amb un prototip que li havia fet una agència a preu tancat, o un cosí que sabia PHP. La mateixa forma: la demo lluïa, el primer client de pagament trobava el primer forat de seguretat, i la pregunta era sempre la mateixa: rescatar o reescriure? Els equips que se'n van sortir no van fer ni una cosa ni l'altra. Van posar un perímetre al voltant del prototip, van substituir les peces que carregaven risc d'una en una i van continuar traient funcionalitats mentrestant. Martin Fowler va batejar el patró com a figuera estranguladora el 2004.

El que la IA ha canviat és la velocitat als dos costats. El prototip arriba en dies en lloc de mesos, i l'arranjament també arriba abans, sempre que l'agent rebi l'única cosa que la construcció original no va tenir mai: una especificació contra la qual executar. Un agent amb un model de dades escrit, criteris d'acceptació i una regla que digui «tota taula porta seguretat a nivell de fila» produeix una base de codi diferent de la d'un agent a qui es diu «afegeix un tauler». Ho veiem cada dia a la nostra pròpia feina: el mateix model, la mateixa eina, i tota la diferència és en el que l'enginyer va escriure abans.

Els primers 30 dies, en l'ordre que aguanta

Si el fundador que ens va escriure fos client meu, treballaria en aquest ordre. L'ordre importa més que la llista.

1. Auditoria de només lectura, dos dies. Inventari del repositori: dependències, rutes, taules, on viuen els secrets, què fa de debò l'script de desplegament. Sense canvis. El resultat és un mapa d'una pàgina del que existeix i una llista del que carrega risc.
2. Tancar el perímetre abans de tocar funcionalitats. Rotar totes les claus que alguna vegada s'hagin confirmat a git. Imposar l'autorització a la capa de dades (seguretat a nivell de fila, no botons amagats). Separar producció de tota la resta i treure el permís d'escriptura a qualsevol agent.
3. Fer el build reproduïble. Dependències fixades, una sola ordre per arrencar en local, un pipeline d'integració contínua que falli quan falla una prova. Fins que això no existeixi, cada arranjament és una aposta.
4. Proves només als camins dels diners. Alta, pagament, permisos, la consulta que seria una bretxa si es filtrés. No cobertura: assegurança. Si el producte crida un model, l'equivalent és una suite d'avaluació que corre amb cada canvi de prompt.
5. Observabilitat i sostres de despesa. Logs amb identificador de petició, seguiment d'errors i un límit dur al que la capa de model pot gastar al dia.
6. Escriure l'especificació que l'MVP no va tenir mai. Model de dades, criteris d'acceptació per funcionalitat, el pla per fases i els fitxers de context (CLAUDE.md, AGENTS.md) que converteixen l'agent de constructor de cap de setmana en júnior disciplinat. És el pas que els fundadors es salten perquè fa olor de paperassa. És el pas que fa previsibles les sis setmanes següents, i per això el venem a part com un Blueprint que el fundador pot executar amb nosaltres, amb la seva pròpia contractació o amb el mateix agent que va escriure la primera versió.
7. Després, i només després, funcionalitats. Sobre una base de codi que ja les pot rebre.

Un enginyer sènior que ja ho hagi fet cobreix els cinc primers passos en dues o tres setmanes. En un altre ordre (primer funcionalitats, el perímetre després) la mateixa feina es menja un trimestre, perquè cada funcionalitat cau sobre sorra i s'ha de refer.

Tres preguntes que decideixen entre conservar i reescriure

• El model de dades descriu el negoci o la conversa? Si les entitats coincideixen amb com parlen els teus clients, conserva'l i migra. Si les taules porten nom de prompt, refés l'esquema i traspassa les dades.
• Algú pot dibuixar en una pissarra el recorregut de la petició més arriscada? Si ningú no pot, l'auditoria va abans que cap decisió.
• El framework és un que un enginyer sènior triaria avui? Next.js, Django, un Postgres gestionat: conservar. Una pila generada per a la qual ningú no contracta al mercat: planifica la sortida ara i executa-la més tard.

La majoria d'MVP fets amb IA que he vist passen la primera pregunta i la tercera. Fallen la segona, i aquesta fallada és a dos dies d'auditoria de quedar resolta.

La demo es va saltar producció. Tu no cal que ho facis

La frase del fundador tenia mitja raó. L'MVP tal com està no ha d'anar a producció, i aquesta no va ser mai la seva feina. La seva feina era demostrar el producte, i ho va fer més ràpid que cap mètode que existís fa tres anys. El que necessita ara és la instal·lació elèctrica, la fontaneria i la llicència, en un ordre conegut, de mans d'algú que ja les hagi instal·lat abans.

Si aquesta és la pregunta que tens al davant, aquest és l'equip que posem en productes de startup: enginyers sènior, validats per CTOs en actiu amb un 3 % d'acceptació, que es fan càrrec d'una base de codi sense que ningú els dicti l'spec i comencen pel perímetre la primera setmana. O comença pel Blueprint, i continua construint amb qui vulguis.