Cum duci un prototip făcut cu AI în producție

Pentru a duce un prototip făcut cu AI în producție, închizi distanța dintre „funcționează când încerc eu” și „continuă să funcționeze când o folosesc alți oameni”. În practică, asta înseamnă cinci lucruri: testezi fluxurile principale de fiecare dată când schimbi ceva, blochezi cine poate vedea și modifica ce, te asiguri că afli despre erori înainte ca utilizatorii tăi să ți le semnaleze, faci copii de siguranță ale datelor și demonstrezi că le poți restaura și păstrezi aplicația suficient de rapidă pe telefon. Nimic din toate acestea nu cere o rescriere — este o listă de verificare pe care o parcurgi împreună cu același AI care a construit prototipul.

Prototip versus producție: ce se schimbă de fapt

Un prototip are un singur utilizator atent: tu. Știi ce butoane să apeși, introduci date de intrare rezonabile și, dacă ceva se strică, ridici din umeri și ceri AI-ului să repare. Producția are mulți utilizatori neglijenți, unii curioși și, ocazional, unul ostil. Codul nu trebuie să devină „de nivel enterprise”; trebuie să gestioneze situațiile pe care un prototip nu le întâlnește niciodată.

Restul ghidului parcurge fiecare rând.

Pasul 1: Blochează domeniul și notează fluxurile principale

Înainte să întărești ceva, decide ce este versiunea întâi. Listează cele trei până la șase fluxuri care contează cel mai mult — de exemplu „înregistrare, creare de proiect, invitare a unui coleg, plată”. Acestea devin scriptul tău de testare, țintele monitorizării și lucrurile pe care le verifici după fiecare modificare.

Tot ce nu este pe listă fie se taie, fie se marchează clar ca beta. Este mult mai ușor să faci patru fluxuri fiabile decât paisprezece.

Pasul 2: Testează ca un străin, apoi fă testarea repetabilă

Constructorii cu AI sunt buni la producerea de cod care funcționează pe calea fericită. Problemele de producție trăiesc pe căile nefericite. Testează fiecare flux principal cu:

• Date de intrare greșite: câmpuri obligatorii goale, un nume de 5.000 de caractere, un email fără @, o cantitate negativă, o dată din trecut.
• Reîncărcări și butonul înapoi: reîncarcă la jumătatea checkout-ului; apasă înapoi după ce trimiți un formular. Se creează ceva de două ori?
• Două file, doi utilizatori: conectează-te cu două conturi diferite și încearcă să deschizi paginile celuilalt schimbând ID-ul din URL.
• Lent și mic: un ecran de dimensiunea unui telefon și o conexiune limitată (uneltele pentru dezvoltatori din browser pot simula asta).
• Stări goale: un cont nou, fără date. Prototipurile sunt adesea construite cu date de exemplu și arată defect fără ele.

Apoi fă verificarea repetabilă. Cel puțin, păstrează o listă de verificare scrisă și rul-o înainte de fiecare lansare. Mai bine, cere AI-ului să scrie teste automate pentru fluxurile care contează cel mai mult:

Adaugă teste automate end-to-end pentru aceste fluxuri: înregistrare cu email, creare de proiect, invitare a unui al doilea utilizator și finalizarea plății în modul de test Stripe. Adaugă și teste care confirmă că un utilizator nu poate vedea sau edita proiectul altui utilizator schimbând URL-ul.

Testele care dovedesc că un utilizator nu poate face ceva sunt cele pe care prototipurile le lipsesc cel mai des.

Pasul 3: Bazele securității pe care prototipurile le sar

Majoritatea problemelor de securitate din aplicațiile construite cu AI nu sunt exotice. Lipsesc verificări. Parcurge această listă și vezi lista completă de verificare de securitate pentru aplicațiile construite cu AI:

• Autorizare pe server. Ascunderea unui buton nu este securitate. Fiecare cerere care citește sau modifică date trebuie să verifice, pe server, că utilizatorul conectat are voie să o facă. Dacă aplicația ta folosește o bază de date cu reguli la nivel de rând, verifică să fie activate și testate.
• Secretele în afara browserului. Cheile API pentru plăți, email sau furnizorii de AI aparțin variabilelor de mediu de pe server, niciodată codului din front-end. Dacă nu ești sigur ce înseamnă asta, citește ce sunt variabilele de mediu și secretele.
• Validare pe server. Browserul poate fi ocolit, așa că repetă pe server orice verificare care contează.
• Autentificare făcută corect. Folosește o bibliotecă sau un serviciu de autentificare bine testat, în loc de stocarea parolelor scrise de mână. Ghidul nostru despre cum adaugi autentificare în aplicația ta prezintă opțiunile.
• Limite de rată pentru autentificare, înregistrare, resetarea parolei și orice trimite email sau apelează un API plătit.
• Erori prietenoase. Utilizatorii trebuie să vadă „a apărut o problemă”; detaliile merg în jurnalele tale, nu pe ecran.
• Rotește tot ce a fost scurs. Dacă o cheie live a fost lipită vreodată într-un chat, un commit sau o captură de ecran, înlocuiește-o la furnizor.

Un prompt care acoperă mult teren deodată:

Verifică această aplicație pentru securitate în producție. Asigură-te că fiecare rută API verifică faptul că utilizatorul conectat este proprietarul înregistrării pe care o citește sau o modifică, că nicio cheie secretă nu ajunge în browser, că datele de intrare sunt validate pe server și că autentificarea și resetarea parolei sunt limitate ca rată. Listează ce găsești înainte să schimbi ceva.

Să ceri mai întâi o listă te lasă să vezi problemele și să decizi ordinea, în loc să primești o modificare uriașă.

Pasul 4: Află când se strică — jurnalizare și monitorizare

În previzualizare vezi erorile pe măsură ce apar. În producție ai nevoie ca aplicația să te anunțe. Trei niveluri, de la cel mai ieftin la cel mai util:

1. Jurnalele serverului. Asigură-te că erorile sunt înregistrate cu suficient context ca să poată fi reproduse: ce rută, ce ID de utilizator (nu parola sau cardul lui), ce formă au datele de intrare. Cere AI-ului să adauge jurnalizare structurată dacă aplicația doar afișează în consolă.
2. Urmărirea erorilor. Un serviciu precum Sentry sau un instrument similar captează excepțiile din front-end și din back-end, le grupează și îți trimite email. Pentru o aplicație mică, planurile gratuite ale acestor servicii sunt adesea suficiente; verifică limitele actuale pe site-urile lor.
3. Verificări de disponibilitate. Un serviciu extern care încarcă pagina principală și o rută API cheie la câteva minute și te alertează dacă eșuează. Asta prinde problemele care opresc aplicația să mai jurnalizeze ceva.

Adaugă un obicei în plus: după fiecare lansare, deschide aplicația live și rulează lista ta de verificare a fluxurilor principale pe adresa reală, nu doar pe previzualizare.

Pasul 5: Copii de siguranță și o cale de revenire

Două lucruri diferite trebuie protejate și sunt ușor de confundat.

• Codul. Păstrează proiectul în control de versiuni, ca orice modificare să poată fi anulată. Mulți constructori cu AI păstrează puncte de control ale fișierelor tale; sincronizarea cu un depozit Git îți oferă o copie și în afara constructorului.
• Datele. Revenirea codului nu readuce baza de date. O migrare proastă sau un buton de ștergere cu bug poate distruge rânduri pe care niciun punct de control al codului nu le va readuce.

Pentru date, configurează copii de siguranță regulate stocate în altă parte decât în găzduirea aplicației — pentru o bază de date Postgres, abordarea obișnuită este un pg_dump programat către un spațiu de stocare separat, iar multe găzduiri de baze de date gestionate oferă copii automate sau recuperare la un punct în timp. Apoi fă pasul pe care îl sar cei mai mulți: restaurează o copie într-o bază de date de test și verifică dacă datele sunt acolo.

Cere de asemenea AI-ului să facă acțiunile distructive mai sigure: un pas de confirmare pentru ștergeri și „ștergere moale” (marcarea rândurilor ca șterse în loc să fie eliminate) pentru orice ar putea vrea utilizatorii înapoi.

Pasul 6: Performanță care ține pe telefon

Prototipurile par rapide pentru că ești singurul utilizator și setul de date este mic. Înainte de lansare:

• Încarcă date de dimensiune reală. Cere AI-ului să populeze câteva mii de rânduri și vezi ce pagini încetinesc. Listele au de obicei nevoie de paginare, iar baza de date are de obicei nevoie de indecși pe coloanele după care filtrezi și sortezi.
• Micșorează imaginile. Imaginile supradimensionate sunt cel mai frecvent motiv pentru care o pagină se încarcă lent. Cere imagini redimensionate, comprimate și încărcare întârziată sub zona vizibilă.
• Măsoară. Rulează Lighthouse din uneltele pentru dezvoltatori ale Chrome pe adresa live, în modul mobil. Core Web Vitals ale Google sunt un obiectiv sensibil: Largest Contentful Paint sub 2,5 secunde, Interaction to Next Paint de 200 ms sau mai puțin și Cumulative Layout Shift de 0,1 sau mai puțin.
• Atenție la întârzierile de „trezire”. Găzduirea care adoarme când nu e folosită economisește bani, dar face prima vizită după o perioadă liniștită mai lentă. Pentru o aplicație nouă, acesta este de obicei un compromis acceptabil; știi că se întâmplă.

Pagina de proiecte este lentă cu 5.000 de rânduri. Adaugă paginare pe server (25 pe pagină), adaugă indecși în baza de date pentru coloanele după care filtrăm și sortăm și afișează o stare de încărcare cât timp se încarcă pagina următoare.

Pasul 7: Elemente operaționale de bază

Câteva lucruri mici despart o aplicație de hobby de una în care oamenii au încredere:

• Un domeniu personalizat cu HTTPS. Vezi cum conectezi un domeniu personalizat.
• Email tranzacțional dintr-un domeniu verificat pentru confirmările de înregistrare și resetările parolei — acoperit în cum trimiți emailuri din aplicația ta.
• Politica de confidențialitate și termenii care descriu ce colectezi de fapt. Nu copia declarații de conformitate pe care nu le-ai îndeplinit.
• O cale de suport — chiar și o adresă de email monitorizată.
• Chei de test și chei live separate pentru plăți și email și o notă clară despre ce mediu folosește ce.

Pasul 8: O predare curată

Mai devreme sau mai târziu, altcineva va lucra la aplicație: un freelancer, un nou cofondator sau tu peste șase luni. Fă asta ușor:

• Un README care spune cum se rulează, de ce variabile de mediu are nevoie (doar nume, niciodată valori) și cum se publică.
• Lista de verificare a fluxurilor principale și testele automate.
• O scurtă notă de arhitectură: front-end, back-end, baza de date, serviciile terțe și unde este găzduit fiecare.
• Lista de acces: cine are acces de administrator la domeniu, găzduire, baza de date, conturile de plăți și email. Pune aceste conturi sub un email de business, nu unul personal.
• Codul în Git, de preferat sincronizat cu un depozit pe care îl deții. Dacă s-ar putea să muți găzduirea mai târziu, citește cum exporți și găzduiești singur o aplicație construită cu AI.

AI-ul poate redacta cea mai mare parte din asta pentru tine:

Scrie un README pentru acest proiect, pentru un dezvoltator care nu l-a văzut niciodată: ce face aplicația, stiva tehnologică, cum se rulează local, fiecare variabilă de mediu pe care o citește (doar nume și scop), cum este organizată schema bazei de date și cum se publică.

Lista de verificare pentru pregătirea producției

• Fluxurile principale scrise și testate, inclusiv „nu poate accesa datele altcuiva”
• Autorizare și validare pe server pentru fiecare rută de date
• Nicio cheie secretă în codul din front-end; chei scurse rotite
• Limite de rată pentru autentificare și pentru orice costă bani
• Urmărirea erorilor și alertele de disponibilitate trimise către o cutie de email pe care o citești
• Copii de siguranță ale bazei de date în afara găzduirii aplicației, cu o restaurare de test reușită
• Paginarea și indecșii verificate cu date realiste
• Domeniu personalizat, domeniu verificat pentru trimitere și politică de confidențialitate
• README și lista de acces pentru cine vine după tine

Cum faci asta cu Mythex

Dacă ai construit prototipul în Mythex, majoritatea pașilor sunt prompturi în același proiect. Scrie /test și Mythex parcurge previzualizarea live ca un utilizator și raportează fluxurile defecte — vezi Testarea aplicației. Cheile intră în secretele proiectului, nu în chat, fiecare tură reușită a agentului salvează un punct de control al fișierelor tale la care te poți întoarce, iar publicarea îți oferă o adresă live cu găzduire, iar baza de date se facturează din același sold de credite (limitele de găzduire explică cum aplicațiile și bazele de date adorm și se trezesc). Punctele de control acoperă fișierele, nu rândurile din baza de date, așa că planifică în continuare copiile de siguranță ale datelor. Pe planul Pro poți conecta un domeniu personalizat și poți exporta codul sau îl poți sincroniza cu propriul depozit GitHub pentru o predare.

Întrebări