Întreținerea aplicațiilor create cu IA: ce nu-ți spune nimeni despre săptămâna a doua

În primul weekend cu Proyecta, lansezi ceva real. Funcționează. Utilizatorii tăi (sau echipa ta, sau tu cel de mâine) încep să-l folosească. Și apoi e luni dimineață și un client îți scrie: „Poți să adaugi un meniu derulant ca să pot filtra după regiune?”.

Bun venit la întreținere. Asta e partea din construirea unei aplicații cu IA despre care nu vorbește nimeni și partea în care majoritatea proiectelor fie devin un activ de lungă durată, fie cad discret în prăpastie. Vestea bună e că întreținerea unei aplicații create cu IA e o experiență diferită de întreținerea codului tradițional. Vestea sinceră e că „diferit” nu înseamnă „gratis”.

Ce înseamnă de fapt întreținerea

Când programatorii profesioniști spun „întreținere”, se referă, mai mult sau mai puțin, la patru lucruri:

Adăugarea de funcții mici pe care oamenii le cer după lansare.
Repararea lucrurilor care s-au stricat sau au fost greșite de la bun început.
Ținerea pasului cu schimbările din afara aplicației tale — un procesator de plăți își actualizează API-ul, apare un browser nou, forma datelor tale se schimbă.
Curățenia, ca să nu se transforme codul încet-încet într-o mlaștină.

Pentru o aplicație creată cu IA, toate patru se întâmplă în continuare. Ce se schimbă e cine le face și cum se simte munca.

Vestea bună: poți vorbi cu ea

Iată partea pe care nu ți-o spunea nimeni pe vremea când copiai cod din tutoriale vechi. Cu un creator de aplicații cu IA, întreții aplicația la fel cum ai construit-o: descriind ce vrei.

Un exemplu real. O fondatoare pe care o cunoaștem a construit un mic CRM pentru cabinetul ei de coaching — clienți, ședințe, urmărirea plăților, tot tacâmul. La trei săptămâni după lansare, o clientă a menționat că i-ar plăcea să vadă câte ședințe făcuse în acel an. A deschis aplicația și a spus: „Adaugă un contor «ședințe anul acesta» pe fiecare fișă de client, care trage din tabelul de ședințe acolo unde data e în 2026”. Douăsprezece minute mai târziu, era live. Ea era deja înapoi la coaching.

Povestea sună normal până îți amintești alternativa: să dai un mesaj unui freelancer, să aștepți două zile, să plătești 300 de dolari, să revizuiești un PR pe care nu-l înțelegea pe deplin și să te rogi să nu se fi stricat altceva. Bucla de întreținere nu e mai rapidă pentru că IA e mai deșteaptă decât freelancerul. E mai rapidă pentru că în buclă sunt mai puțini oameni.

Vestea mai grea: lucrurile mărunte se adună

Iată partea care îi prinde pe oameni nepregătiți. Aplicațiile create cu IA par ușor de schimbat pentru că adăugarea de lucruri e ușoară. Ce nu e ușor e să păstrezi întregul coerent pe măsură ce crește.

Câteva tipare pe care le vedem cum o iau razna:

Încâlceala accidentală. Ceri „adaugă un câmp de reducere la finalizarea comenzii”. După șase revizuiri, logica reducerii trăiește în trei locuri și doar unul dintre ele e corect. Încă nu s-a stricat nimic, dar următoarea modificare va fi derutantă.
Cerința uitată. Ai adăugat „livrare gratuită peste 50 de dolari” în martie. În mai, ceri IA să „refacă finalizarea comenzii ca să suporte carduri-cadou”. O face. Regula de livrare gratuită a dispărut. Nimeni n-a observat timp de două săptămâni.
Devierea. Aplicația ta a pornit ca „un instrument pentru mine”. Acum o folosește echipa ta. Modelul mental din care lucrează IA e tot „pentru mine”, pentru că asta ai spus inițial. Funcțiile noi par ciudat de nepotrivite și nu reușești să-ți dai seama de ce.

Niciuna dintre acestea nu e un eșec al creatorilor de aplicații cu IA. Sunt eșecuri de memorie și de context comun — exact aceleași probleme pe care le are o echipă de programatori umani, doar într-o altă formă.

Cum să te organizezi

Echipele care se descurcă bine la întreținere au câteva obiceiuri în comun. Nu sunt obiceiuri tehnice, în mare parte. Sunt obiceiuri legate de felul în care descrii ce este aplicația ta și ce s-a schimbat.

Ține un document „ce este această aplicație”. O pagină. Publicul, obiectivele, regulile („livrare gratuită peste 50 de dolari”, „nu trimitem niciodată e-mailuri utilizatorilor duminica”, „telefonul e cheia principală, nu e-mailul”). Când ceri IA să schimbe ceva, lipește regula relevantă în prompt. Nu ocolești inteligența IA; îi furnizezi contextul pe care n-are cum să-l țină minte.

Descrie schimbările în termeni de comportament, nu de cod. „Vreau ca utilizatorii să-și vadă filtrul de regiune reținut între sesiuni” e o cerere mult mai bună decât „adaugă localStorage la filtru”. Prima descrie ce vrei; a doua prescrie una dintre cincisprezece moduri de a o face și probabil nu cel mai bun.

Fă modificările pe rând. Două modificări într-un singur prompt înseamnă că una ar putea eșua în tăcere și nu vei ști care. Cea mai rapidă cale de a întreține o aplicație cu IA e să-ți păstrezi iterațiile destul de mici încât să-ți dai seama dintr-o privire dacă rezultatul e corect.

Uită-te la ce s-a schimbat. Majoritatea creatorilor de aplicații cu IA îți arată o previzualizare. Folosește-o. Cele treizeci de secunde pe care le petreci dând clic peste tot ca să confirmi că funcția nouă merge și că funcțiile vechi încă merg sunt cea mai ieftină asigurare pe care o vei cumpăra anul acesta.

Ce nu poți face (și probabil nici n-ar trebui)

Există o tentație, odată ce ai construit o aplicație cu IA, să crezi că ea o poate și opera în locul tău. Nu poate, iar diferența e reală:

Nu îți va spune când ceva s-a stricat în tăcere. Jurnale, monitorizare, ture de gardă — astea sunt în continuare o preocupare separată. Majoritatea creatorilor de aplicații cu IA nu îți urmăresc aplicația în producție așa cum ar face-o un inginer de backend.
Nu știe despre lumea din afara aplicației tale. Dacă un procesator de plăți scoate din uz un API, IA nu știe până nu-i spui. Abonează-te la istoricele de modificări ale furnizorilor tăi. Citește-ți e-mailul.
Nu poate lua deciziile de produs în locul tău. Dacă să adaugi sau nu o funcție, ce compromis să faci, ce vor cu adevărat utilizatorii tăi — astea ești tot tu. IA e o pereche de mâini foarte rapide; creierul e al tău.

Tabloul realist

După șase luni cu o aplicație creată cu IA, majoritatea oamenilor cu care vorbim ajung cam aici: petrec poate două-patru ore pe lună cu modificări, aproape totul prin conversație. Refacerile mari de care se temeau cândva — „vreau să adaug o secțiune complet nouă” — se simt acum ca o după-amiază bună. Lucrurile plictisitoare — „formatul datei e greșit la export” — se simt ca un prompt bun.

Ce nu mai au e zgomotul de fond constant al unui cod tradițional: actualizări de dependențe, migrări de framework, patch-uri de securitate, configurări de build. Acel zgomot a fost absorbit de platformă. Plătești ca platforma să se ocupe de el, ceea ce e o afacere mult mai bună decât să plătești un programator să se ocupe de el.

Dacă urmează să-ți construiești prima aplicație, articolul despre ce ar trebui să fie prima ta aplicație creată cu IA merită citit înainte să începi. Iar dacă ești deja la câteva săptămâni distanță și simți unele dintre tiparele de mai sus, e normal. Scrie-ți documentul „ce este această aplicație” chiar în acest weekend. Tu cel de peste trei luni, care va cere un panou de control nou, îți va fi tare recunoscător că ai făcut-o.