Com portar un prototip d'IA a producció

Per portar un prototip d'IA a producció, has de tancar la distància entre «funciona quan ho provo» i «continua funcionant quan la gent l'utilitza». A la pràctica, això vol dir cinc coses: provar els fluxos principals cada vegada que canvies alguna cosa, bloquejar qui pot veure i modificar cada cosa, assegurar-te que t'enterres dels errors abans que t'ho diguin els usuaris, fer còpies de seguretat de les dades i demostrar que pots restaurar-les, i mantenir l'aplicació prou ràpida en un mòbil. Res d'això requereix reescriure-ho tot: és una llista de verificació que vas completant amb la mateixa IA que va construir el prototip.

Prototip contra producció: què canvia de veritat

Un prototip té un únic usuari atent: tu. Saps quins botons prémer, escrius dades sensates i, si alguna cosa falla, t'encongeixes d'espatlles i demanes a la IA que ho arregli. La producció té molts usuaris descuidats, alguns curiosos i, de tant en tant, un d'hostil. El codi no cal que es converteixi en «empresarial»; cal que gestioni les situacions que un prototip mai no arriba a trobar.

La resta d'aquesta guia repassa cada fila.

Pas 1: Congela l'abast i escriu els fluxos principals

Abans de reforçar res, decideix què és la versió 1. Fes una llista dels tres a sis fluxos més importants — per exemple, «registrar-se, crear un projecte, convidar un company, pagar». Aquests seran el teu guió de proves, els objectius de monitoratge i les coses que comproves després de cada canvi.

Tot el que no hi sigui o bé es talla o bé es marca clarament com a beta. És molt més fàcil fer fiables quatre fluxos que catorze.

Pas 2: Prova com un desconegut i després fes-ho repetible

Els constructors amb IA són bons generant codi que funciona en el cas ideal. Els problemes de producció viuen en els camins no ideals. Prova cada flux principal amb:

• Dades incorrectes: camps obligatoris buits, un nom de 5.000 caràcters, un correu sense @, una quantitat negativa, una data al passat.
• Recàrregues i el botó enrere: recarrega a mig pagament; prem enrere després d'enviar un formulari. Es crea alguna cosa dues vegades?
• Dues pestanyes, dos usuaris: inicia sessió amb dos comptes diferents i prova d'obrir les pàgines de l'altre canviant l'ID de la URL.
• Lent i petit: una pantalla de mida de mòbil i una connexió limitada (les eines de desenvolupador del navegador en poden simular una).
• Estats buits: un compte nou sense dades. Els prototips sovint es construeixen amb dades d'exemple i semblen trencats sense elles.

Després fes que la comprovació sigui repetible. Com a mínim, mantén una llista escrita i executa-la abans de cada versió. Millor encara, demana a la IA que escrigui proves automatitzades per als fluxos més importants:

Afegeix proves automatitzades de extrem a extrem per a aquests fluxos: registrar-se amb correu, crear un projecte, convidar un segon usuari i completar un pagament a Stripe en mode de prova. Afegeix també proves que confirmin que un usuari no pot veure ni editar el projecte d'un altre canviant la URL.

Les proves que demostren que un usuari no pot fer alguna cosa són les que més sovint falten als prototips.

Pas 3: Bases de seguretat que els prototips s'ometen

La majoria de problemes de seguretat en les aplicacions creades amb IA no són exòtics. Són comprovacions que falten. Repassa aquesta llista, i consulta la llista de verificació de seguretat per a aplicacions creades amb IA, més completa:

• Autorització al servidor. Amagar un botó no és seguretat. Cada sol·licitud que llegeix o modifica dades ha de comprovar, al servidor, que l'usuari connectat hi té dret. Si la teva aplicació fa servir una base de dades amb regles per fila, comprova que estiguin activades i provades.
• Secrets fora del navegador. Les claus d'API de pagaments, correu o proveïdors d'IA han d'estar en variables d'entorn del servidor, mai en codi del front-end. Si no tens clar què vol dir, llegeix què són les variables d'entorn i els secrets.
• Validació al servidor. El navegador es pot saltar, així que repeteix al servidor qualsevol comprovació que importi.
• Inici de sessió fet bé. Fes servir una biblioteca o un servei d'autenticació ben provats en lloc de guardar contrasenyes a mà. La nostra guia com afegir inici de sessió a la teva aplicació explica les opcions.
• Límits de peticions a l'inici de sessió, el registre, el restabliment de contrasenya i qualsevol cosa que envii correus o cridi una API de pagament.
• Errors amigables. Els usuaris han de veure «alguna cosa ha fallat»; els detalls van als teus registres, no a la pantalla.
• Canvia qualsevol cosa que s'hagi filtrat. Si una clau real es va enganxar mai en un xat, un commit o una captura de pantalla, substitueix-la al proveïdor.

Una indicació que cobreix molt terreny alhora:

Revisa aquesta aplicació per a la seguretat en producció. Comprova que cada ruta d'API verifica que l'usuari connectat és propietari del registre que llegeix o modifica, que cap clau secreta s'envia al navegador, que les dades d'entrada es validen al servidor i que l'inici de sessió i el restabliment de contrasenya tenen límit de peticions. Fes una llista del que trobis abans de canviar res.

Demanar primer una llista permet veure els problemes i decidir l'ordre, en lloc de rebre un canvi enorme.

Pas 4: Saber quan es trenca: registres i monitoratge

A la vista prèvia veus els errors a mesura que passen. En producció necessites que l'aplicació t'ho digui. Tres capes, de la més barata a la més útil:

1. Registres del servidor. Assegura't que els errors es registren amb prou context per reproduir-los: quina ruta, quin ID d'usuari (no la seva contrasenya ni la targeta) i quina forma tenien les dades d'entrada. Demana a la IA que afegeixi registres estructurats si l'aplicació només escriu a la consola.
2. Seguiment d'errors. Un servei com Sentry o una eina similar captura les excepcions del front-end i del back-end, les agrupa i t'envia un correu. Per a una aplicació petita, els plans gratuïts d'aquests serveis solen ser suficients; consulta els límits actuals als seus llocs web.
3. Comprovacions de disponibilitat. Un servei extern que carrega la teva pàgina d'inici i una ruta clau de l'API cada pocs minuts i t'avisa si fallen. Això detecta els problemes que impedeixen que l'aplicació registri res.

Afegeix un hàbit més: després de cada versió, obre l'aplicació en directe i executa la llista de fluxos principals a la URL real, no només a la vista prèvia.

Pas 5: Còpies de seguretat i una manera de tornar enrere

Hi ha dues coses diferents que cal protegir, i són fàcils de confondre.

• Codi. Guarda el projecte en un sistema de control de versions perquè qualsevol canvi es pugui desfer. Molts constructors amb IA guarden punts de control dels fitxers; sincronitzar-ho amb un repositori de Git et dona una còpia fora del constructor.
• Dades. Desfer el codi no desfà la base de dades. Una migració dolenta o un botó d'esborrar amb errors pot destruir files que cap punt de control del codi recuperarà.

Per a les dades, configura còpies de seguretat periòdiques guardades en un lloc diferent de l'allotjament de l'aplicació — per a una base de dades Postgres, la manera habitual és un pg_dump programat cap a un emmagatzematge separat, i molts proveïdors de bases de dades gestionades ofereixen còpies automàtiques o recuperació a un punt concret en el temps. Després fes el pas que més gent s'ometen: restaura una còpia en una base de dades de proves i comprova que les dades hi són.

Demana també a la IA que faci més segures les accions destructives: un pas de confirmació per als esborrats i un «esborrat suau» (marcar les files com a eliminades en lloc de treure-les) per a qualsevol cosa que els usuaris puguin voler recuperar.

Pas 6: Rendiment que aguanta en un mòbil

Els prototips semblen ràpids perquè només els uses tu i les dades són petites. Abans de llançar-te:

• Carrega dades de mida real. Demana a la IA que inserti alguns milers de files i mira quines pàgines s'alenteixen. Les llistes solen necessitar paginació i la base de dades sol necessitar índexs a les columnes per les quals filtres i ordenes.
• Redueix les imatges. Les imatges massa grans són el motiu més habitual de càrrega lenta d'una pàgina. Demana imatges redimensionades i comprimides, i càrrega diferida per sota de la línia de plegat.
• Mesura. Executa Lighthouse a les eines de desenvolupador de Chrome sobre la URL en directe en mode mòbil. Les Core Web Vitals de Google són un objectiu sensat: Largest Contentful Paint dins de 2,5 segons, Interaction to Next Paint de 200 ms o menys, i Cumulative Layout Shift de 0,1 o menys.
• Vigila els retards de «despertar». Un allotjament que es posa a dormir quan està inactiu estalvia diners, però fa que la primera visita després d'un període tranquil sigui més lenta. Sovint és un bon compromís per a una aplicació nova; sàpigues que passa.

La pàgina de projectes és lenta amb 5.000 files. Afegeix paginació al servidor (25 per pàgina), afegeix índexs a la base de dades per a les columnes que filtrem i ordenem, i mostra un estat de càrrega mentre es carrega la pàgina següent.

Pas 7: Bàsics operatius

Unes quantes petites coses separen una aplicació de passatemps d'una que la gent es fia:

• Un domini personalitzat amb HTTPS. Consulta com connectar un domini personalitzat.
• Correu transaccional des d'un domini verificat per a les confirmacions de registre i els restabliments de contrasenya — explicat a com enviar correus des de la teva aplicació.
• Política de privadesa i condicions que descriguin el que recopiles realment. No copiïs afirmacions de compliment que no t'hagis guanyat.
• Una via de suport — com a mínim, una adreça de correu que algú llegeixi.
• Claus de prova i de producció separades per als pagaments i el correu, i una nota clara de quin entorn fa servir cada una.

Pas 8: Un traspàs ordenat

Tard o d'hora algú més treballarà en l'aplicació: un autònom, un nou cofundador o tu d'aquí a sis mesos. Facilita-ho:

• Un README que expliqui com executar-la, quines variables d'entorn necessita (només els noms, mai els valors) i com desplegar-la.
• La llista de fluxos principals i les proves automatitzades.
• Una nota breu d'arquitectura: front-end, back-end, base de dades, serveis de tercers i on s'allotja cadascun.
• Llista d'accessos: qui té accés d'administrador al domini, a l'allotjament, a la base de dades, i als comptes de pagament i de correu. Posa aquests comptes sota un correu de l'empresa, no un personal.
• El codi a Git, idealment sincronitzat amb un repositori que siguin teu. Si és possible que canviïs d'allotjament més endavant, llegeix com exportar i autoallotjar una aplicació creada amb IA.

La IA pot redactar gran part d'això per a tu:

Escriu un README per a aquest projecte per a un desenvolupador que mai no l'ha vist: què fa l'aplicació, la pila tecnològica, com executar-la en local, cada variable d'entorn que llegeix (només noms i funció), com s'organitza l'esquema de la base de dades i com desplegar-la.

Llista de verificació de preparació per a producció

• Fluxos principals escrits i provats, inclosa la prova «no pot accedir a les dades d'un altre»
• Autorització i validació al servidor a cada ruta de dades
• Cap clau secreta al codi del front-end; claus filtrades substituïdes
• Límits de peticions a l'autenticació i a qualsevol cosa que tingui cost
• Seguiment d'errors i alertes de disponibilitat que apunten a una safata d'entrada que llegeixis
• Còpies de seguretat de la base de dades fora de l'allotjament de l'aplicació, amb una restauració de prova reeixida
• Paginació i índexs comprovats amb dades realistes
• Domini personalitzat, domini d'enviament verificat, política de privadesa
• README i llista d'accessos per a qui vingui després

Fer-ho amb Mythex

Si has construït el prototip a Mythex, la majoria d'aquests passos són indicacions dins del mateix projecte. Escriu /test i Mythex fa clic a la vista prèvia en directe com un usuari i informa dels fluxos trencats — consulta Proves de l'aplicació. Les claus es posen als secrets del projecte i no al xat; cada torn de l'agent que finalitza bé desa un punt de control dels teus fitxers al qual pots tornar; i publicar-ho et dona una URL en directe, amb allotjament i base de dades facturats des del mateix saldo de crèdits (límits d'allotjament explica com les aplicacions i les bases de dades es posen a dormir i es desperten). Els punts de control cobreixen fitxers, no files de la base de dades, així que igualment has de planificar les còpies de les dades. Al pla Pro pots connectar un domini personalitzat i exportar el codi o sincronitzar-lo amb el teu propi repositori de GitHub per al traspàs.

Preguntes