MVP-ul tău făcut cu AI tocmai a primit utilizatori. Iată ce cedează primul.

I-ai descris unei unelte AI o aplicație într-un weekend, iar ea a construit-o. Arăta bine, ai pus-o în fața oamenilor și unii au rămas. Asta nu e noroc. Ai găsit o problemă reală și ai livrat ceva ce oamenii folosesc, care e partea grea, și ai făcut-o fără să angajezi pe nimeni. Greșeala e să tratezi ce urmează ca pe o trădare. AI-ul face ușor să construiești ceva frumos. Nu face ușor să ții acel lucru în picioare odată ce utilizatori reali se sprijină pe el.

Acesta e momentul în care mulți fondatori intră în panică și pun întrebarea greșită: rescriu tot, sau merg mai departe șchiopătând? Aproape mereu există un răspuns mai calm și mai ieftin la mijloc. Dar ca să ajungi la el trebuie să știi ce cedează de fapt.

Ce cedează primul

Funcțiile pe care le vezi sunt de obicei în regulă. Un formular de login se afișează, un dashboard se încarcă, o înregistrare se salvează. Ce cedează e partea pe care demoul nu a testat-o niciodată, fiindcă un demo rulează scenariul fericit o dată, iar un utilizator real rulează toate scenariile deodată.

• Autorizarea, nu autentificarea. Loginul funcționează. Ce lipsește e verificarea pe server că ai voie să vezi această înregistrare. Aplicațiile făcute cu AI blochează frecvent interfața („ascunde butonul de admin") fără să blocheze API-ul, așa că oricine ghicește un URL sau modifică o cerere vede datele tuturor. Asta e cedarea care ajunge titlu de știre.
• Modelul de date. O schemă construită ca să meargă demoul e croită pentru un singur utilizator care face un singur lucru. Nu are constrângeri, nu are indecși și are presupuneri care se prăbușesc în clipa în care doi utilizatori acționează simultan sau un tabel trece de câteva mii de rânduri.
• Gestionarea erorilor. Codul generat tratează cazul care i-a fost arătat. API-ul extern care expiră, plata care se face pe jumătate, încărcarea care eșuează la mijloc: acele scenarii nu au fost scrise niciodată, așa că eșuează în tăcere, iar tu afli de la un utilizator confuz, nu dintr-un log.
• Costul și limitele de rată. Dacă aplicația apelează un model AI, adesea nu există nicio limită și niciun cache. O buclă de reîncercare care asaltează un furnizor, sau o singură zi virală, ajunge ca o factură.

Niciuna nu se vede într-un demo. Toate se văd la utilizatori. Acea diferență e toată problema, și de aceea „mergea când am construit-o" și „cedează acum" sunt amândouă adevărate.

Consolidezi sau rescrii?

Instinctul după primul incident e să rescrii de la zero. De obicei asta e alegerea scumpă. O rescriere aruncă singurul lucru pe care MVP-ul ți l-a câștigat, anume dovada a ceea ce fac de fapt utilizatorii, și petrece luni reconstruind funcții care deja mergeau în timp ce te oprești din livrat. Întrebarea nu e „e codul perfect", e „e fundația suficient de solidă ca să construiești pe ea".

Ce înseamnă de fapt „consolidare"

Consolidarea nu e spectaculoasă și nu e o rescriere. E să găsești riscurile portante și să le repari în ordinea priorității în timp ce produsul rămâne în funcțiune. Adaugă verificări reale de autorizare pe server. Pune constrângeri și indecși pe modelul de date înainte să crească mai mult. Învelește apelurile externe care eșuează în tăcere. Limitează și pune cache pe apelurile către model. Adaugă suficientă observabilitate încât următoarea problemă să apară într-un log înainte să apară în inbox. Fiecare reparație e mică. Făcute în ordinea corectă, te mută de la „cedează sub sarcină" la „plictisitor și fiabil" fără o singură lună pierdută nelivrând.

Capcana de partea cealaltă e să tratezi consolidarea ca pe un refactoring fără sfârșit. Nu faci codul frumos. Cuantifici riscurile și le retragi pe cele care schimbă dacă produsul supraviețuiește contactului cu utilizatorii. E aceeași disciplină ca un audit de due diligence tehnic, îndreptat spre propriul produs în loc de o achiziție.

Când rescrierea e opțiunea mai ieftină

Uneori răspunsul onest e rescrierea, și a pretinde altceva costă mai mult. Cel mai clar semnal e modelul de date. Dacă forma datelor e greșită pentru ce s-a dovedit a fi produsul, și fiecare funcție e construită pe acea formă, peticirea în jurul ei devine mai scumpă în fiecare săptămână. O rescriere țintită a stratului de date, păstrând interfața și fluxurile validate, e adesea mutarea reală. O rescriere completă de la zero e rară, și e justificată mai ales când nimeni nu poate schimba codul în siguranță deloc: fără teste, fără documentație, autorul original plecat, fiecare modificare stricând ceva fără legătură. În acel punct întreții cod moștenit pe care s-a întâmplat să-l scrii luna trecută.

Prima mutare e un audit, nu o decizie

Nu poți alege între consolidare și rescriere din anxietate. Alegi dintr-o hartă. Înainte să atingem o aplicație făcută prin vibe coding, rulăm un audit de preluare: ce face de fapt codul, unde sunt riscurile reale și care dintre ele schimbă decizia. Rezultatul e o listă ordonată, fiecare punct cu o severitate și un cost aproximativ de reparat, ca decizia consolidare-sau-rescriere să fie luată pe dovezi în loc de o săptămână proastă. Am descris tiparele specifice de cedare pe care tot le găsim în auditul codului generat cu AI.

Dacă MVP-ul tău făcut cu AI tocmai a găsit utilizatori și a început să scârțâie, asta e o problemă bună, și are un răspuns calm. Obține o evaluare înainte să decizi: încearcă estimatorul de MVP ca să dimensionezi munca, sau programează o discuție și îți vom spune onest dacă ar trebui să consolidezi sau să rescrii, inclusiv când răspunsul e „lasă-o în pace deocamdată".