La doi ani și jumătate distanță, tocmai această ordine merită păstrată. Echipele care câștigă ceva real de pe urma agenților AI de programare tratează specificația scrisă și verificarea ei ca muncă de inginerie. Codul generat e partea ieftină. Un furnizor care nu vă poate arăta cine a aprobat planul înainte să pornească agentul nu are un proces de verificare, oricât de bine ar arăta pull requestul de la final.
Articolul de lansare al GitHub (29 aprilie 2024) descria un flux de lucru centrat pe sarcină, care pornește de la un repository sau de la un issue. Workspace propunea apoi un plan pas cu pas pentru rezolvarea issue-ului, lăsa totul editabil, de la plan până la cod, și se încheia cu pașii obișnuiți: deschiderea pull requestului, rularea GitHub Actions și a scanării de securitate, code review făcut de colegi.
Echipa GitHub Next a explicat structura mai în detaliu, în aceeași zi, într-un comentariu pe Hacker News. Specificația avea puncte „current”, adică felul în care agentul înțelege sistemul de azi, și puncte „proposed”, adică ce trebuie să fie adevărat după modificare. Planul făcea legătura dintre ele. Fiecare putea fi corectat înainte ca agentul să atingă vreun fișier. Același comentariu spune ceea ce susține și acest articol: un issue bine specificat contează la fel de mult pentru oameni ca pentru AI, iar „bine specificat” nu înseamnă „mai mult”, ci „mai clar”.
Primele impresii au fost amestecate, iar tiparul din ele contează mai mult decât verdictul. Austin Henley, care lucrase anterior cu echipa GitHub Next, a descris câteva zile de folosire (29 aprilie 2024). Concluzia lui: planul generat era de obicei bun. Codul, nu. Henley a scris că instrumentul era lent, că codul generat era adesea plin de buguri sau nu avea legătură cu specificația și că ar fi folosit cod doar din 2 dintre cele 12 sesiuni ale sale.
Privit retrospectiv, planul era deja cel mai fiabil rezultat al sistemului. Modelele de atunci descriau des modificarea corectă, apoi nu reușeau s-o facă. Planul era locul unde un om putea aduce cea mai multă valoare cu cel mai mic efort.
Workspace, ca produs, nu a supraviețuit. GitHub Next a încheiat previzualizarea tehnică pe 30 mai 2025 și le-a recomandat utilizatorilor modul agent din VS Code și noul Copilot coding agent, recunoscând deschis că acestea nu fac exact ce făcea Workspace.
Anunțul Copilot coding agent (19 mai 2025) a mutat punctul de plecare înapoi la issue: îi atribuiți issue-ul lui Copilot, iar acesta lucrează în fundal și face push într-un draft pull request. Editorul de plan din browser dispăruse, așa că textul issue-ului a devenit specificația. Același articol a pus a doua barieră în setările implicite: programatorul care îi cere agentului un pull request nu îl poate aproba tot el, iar workflow-urile din Actions nu rulează fără aprobare. GitHub a spus și unde se aștepta ca agentul să se descurce bine: la sarcini de complexitate mică și medie, în proiecte bine acoperite de teste.
În septembrie 2025, GitHub a publicat Spec Kit (2 septembrie 2025), un set de instrumente open source care împarte munca în patru etape (specificare, plan, sarcini, implementare), cu un punct de control după fiecare. Diagnosticul lui pentru munca ratată a agenților este că problema ține de felul în care lucrăm noi, nu de capacitatea agentului de a scrie cod, și că agenții se poartă ca niște parteneri de programare care iau totul ad litteram.
Puse în ordine, aceste evenimente sugerează că ecranul cu planul editabil a fost un experiment de produs care s-a încheiat, iar disciplina „întâi planul, apoi codul” s-a mutat în issue, în repository și în procesul echipei. Acolo îi este locul, pentru că e o decizie despre muncă, nu o funcție a unui instrument anume.
Pentru modificările importante scrise de un agent, recomand verificarea separată a planului și a implementării. Sunt întrebări diferite; același lider tehnic poate face ambele verificări dacă este independent de implementare și de persoana care a cerut modificarea.
Aprobarea planului stabilește dacă aceasta este modificarea potrivită. Descrie specificația sistemul așa cum este azi? Starea propusă corespunde nevoii firmei? Sunt numite cazurile-limită? Responsabilul este cel care înțelege domeniul și sistemul: de multe ori liderul tehnic, uneori un product owner care lucrează alături de un inginer.
Code review-ul pe pull request stabilește dacă modificarea este corectă și sigură. Face codul ce spune specificația aprobată, și nimic în plus? Acoperă testele comportamentul nou? S-a modificat ceva ce nu trebuia atins? Responsabilul este un reviewer care nu a cerut modificarea. Regula implicită a GitHub, prin care cel care cere modificarea nu o poate aproba, exact asta face.
Greșeala frecventă este contopirea celor două aprobări. Când singura verificare are loc la pull request, reviewerul trebuie să reconstituie intenția din diff. Un issue vag, de tipul „adaugă reduceri la checkout”, produce atunci un pull request sigur pe el, care compilează, trece testele scrise tot de agent și implementează doar unul dintre sensurile rezonabile ale cuvântului „reducere”. Review-ul prinde probleme de stil și ratează faptul că s-a construit altceva decât trebuia. Un issue clar numește regula (ce clienți, ce produse, dacă reducerile se cumulează, ce se întâmplă la retur) și spune cum arată succesul. Scrierea acestui text este munca de inginerie. Este și partea pe care o poate citi clientul.
Critica lui Henley este cel mai bun argument împotriva lucrului cu agenți pornind de la specificație și rămâne parțial valabilă. El susținea că fluxul dintr-o singură trecere sare peste toți pașii în care programatorul intră în cod și își construiește un model mental al felului în care funcționează, iar varianta corectă este una iterativă: formulezi sarcina, rafinezi planul, alegi modificările, verifici și o iei de la capăt. Din acest unghi, o specificație mare scrisă dinainte este waterfall sub alt nume, iar înțelegerea care face o specificație bună vine doar din lucrul efectiv în cod.
Are dreptate că specificația nu se poate scrie izolat și nici nu poate fi înghețată. Din același motiv, Spec Kit numește specificațiile documente „vii”. Iterația privește însă felul în care se scrie specificația, nu dacă ea este verificată înainte de generarea codului. Bucla ieftină este să revizuiți un paragraf. Bucla scumpă este review-ul unui diff de 600 de linii construit pe o neînțelegere.
În unele situații, pornirea de la specificație e instrumentul greșit, iar asta face parte din argument.
Dacă un furnizor vă spune că folosește agenți AI de programare, cereți-i să vă arate o modificare recentă: specificația aprobată, pull requestul, cine le-a verificat și ce teste au rulat. Verificați dacă intenția a fost analizată înaintea implementării și dacă persoana care verifică codul este independentă de implementare și de cel care a cerut modificarea. Același lider tehnic poate aproba planul și verifica pull requestul; două nume diferite nu dovedesc singure independența. Software-ul construit cu AI are nevoie de un inginer (în engleză) care să răspundă pentru el.
Copilot Workspace avea dreptate în privința ordinii ecranelor. De atunci, agenții au ajuns să scrie cod mult mai bine, iar asta face specificația și verificarea ei și mai importante, pentru că ele decid acum dacă acel cod valorează ceva.
Toate sursele sunt în limba engleză.
]]>Cred că majoritatea firmelor mici și mijlocii au nevoie de mult mai puțină muncă de conformitate decât li se vinde. O firmă care folosește instrumente AI sau adaugă un chatbot ori o funcție AI în produsul ei, fără să construiască sisteme cu risc ridicat, ar trebui să înceapă cu trei verificări practice: să știe ce sisteme AI folosește și în ce rol, să ia măsuri ca oamenii care le folosesc să le înțeleagă și să stabilească obligațiile de transparență ale sistemelor. Pentru furnizorii de chatboturi, informarea vizibilă este doar una dintre ele. O firmă care cumpără un program amplu de conformitate înainte de acest inventar plătește pentru frică, pentru că încă nu știe ce reguli i se aplică.
Comunicatul Consiliului descria o lege construită pe niveluri de risc: practici interzise, cum ar fi evaluarea socială a persoanelor („social scoring”), sisteme cu risc ridicat permise, dar supuse unor cerințe înainte de a ajunge pe piață, și obligații de transparență foarte ușoare pentru sistemele cu risc limitat. TechCrunch (în engleză) încadra chatboturile, chiar în aceeași zi, în această ultimă categorie. Textul a apărut în Jurnalul Oficial ca Regulamentul (UE) 2024/1689 pe 12 iulie 2024 și a intrat în vigoare la 1 august 2024, cu aplicare etapizată.
Din etapizare a venit cea mai mare parte a confuziei de mai târziu. În iulie 2026, UE a adoptat Regulamentul (UE) 2026/1744, „Digital Omnibus on AI”, în vigoare de la 27 iulie 2026. Considerentele lui spun că întârzierea standardelor și a cadrelor naționale a dus la o sarcină de conformitate mai mare decât cea anticipată. Citit împreună cu regulamentul inițial, calendarul arată așa în noiembrie 2026:
| Regula | Se aplică de la |
|---|---|
| Practicile interzise (articolul 5) și obligația privind cunoștințele despre AI (articolul 4) | 2 februarie 2025 |
| Două interdicții noi: imagini sexuale generate fără consimțământ și materiale cu abuz sexual asupra copiilor | 2 decembrie 2026 |
| Obligațiile de transparență pentru chatboturi, deepfake-uri și conținut generat (articolul 50) | 2 august 2026 |
| Marcarea conținutului generat într-un format care poate fi citit automat, pentru sistemele aflate pe piață înainte de 2 august 2026 | 2 decembrie 2026 |
| Sistemele cu risc ridicat din anexa III (angajare, credit, educație și altele) | 2 decembrie 2027 |
| Sistemele AI cu risc ridicat din produse reglementate (anexa I) | 2 august 2028 |
Mare parte din ce s-a scris despre regulament înainte de iulie 2026 dă vechile termene pentru riscul ridicat. Verificați data oricărui sfat înainte să plătiți pentru el.
Regulamentul împarte obligațiile după rol. Furnizorul (articolul 3 punctul 3) este cel care dezvoltă un sistem AI sau comandă dezvoltarea lui și îl introduce pe piață ori îl pune în funcțiune sub propriul nume sau propria marcă. Implementatorul (articolul 3 punctul 4; în engleză, „deployer”) este oricine folosește un sistem AI aflat sub autoritatea sa, în afara unei activități strict personale, fără caracter profesional.
O firmă care plătește abonamente ChatGPT sau Copilot pentru angajați este implementator. Furnizorul este producătorul instrumentului, iar obligațiile grele sunt ale lui.
Cazul care merită mai multă atenție este firma mică ce construiește un chatbot pentru clienți folosind API-ul unui model și îl pune pe propriul site, sub propriul nume. După cum citesc eu articolul 3 punctul 3, firma aceasta este furnizorul chatbotului ca sistem AI, chiar dacă modelul din spate l-a antrenat altcineva. Contează pentru mai mult decât o informare vizibilă. Articolul 50 alineatul (1) pune informarea în sarcina furnizorului: persoanele trebuie să afle că interacționează cu un sistem AI, cu excepția cazului în care lucrul acesta este evident pentru o persoană rezonabil de bine informată, atentă și prudentă, în împrejurările date. Alineatul (5) cere ca informarea să ajungă la ele cel târziu la prima interacțiune. Articolul 50 alineatul (1) exceptează și sistemele autorizate prin lege pentru detectarea, prevenirea, investigarea sau urmărirea penală a infracțiunilor, cu garanții pentru terți, cu excepția celor puse la dispoziția publicului pentru raportarea unei infracțiuni. Pentru un chatbot obișnuit destinat clienților, punctul de plecare este o frază clară în fereastra de chat și în primul mesaj, o informare care trebuie verificată și pentru accesibilitate și momentul afișării.
Articolul 50 alineatul (2) cere și marcarea într-un format care poate fi citit automat și detectarea conținutului sintetic generat de sisteme AI: text, sunet, imagine sau video. Soluțiile trebuie să fie eficace, interoperabile, robuste și fiabile în măsura posibilului tehnic, ținând seama de limitele conținutului, costuri și stadiul tehnicii. Sunt exceptate sistemele în măsura în care asistă editarea obișnuită sau nu modifică substanțial datele introduse de implementator ori sensul lor, precum și utilizările autorizate prin lege în materie penală. Generarea liberă într-un chatbot nu este automat editare obișnuită. Notați ce model sau platformă asigură marcajele, dacă aplicația le păstrează la afișare și export, cum verificați detectarea și temeiul oricărei excepții. Eticheta din fereastra de chat nu rezolvă singură această obligație.
Inventarul este un document scurt, ținut la zi, cu un rând pentru fiecare sistem AI: instrumentul sau funcția, cine îl folosește, pentru ce, dacă sunteți furnizor sau implementator și dacă folosirea lui atinge vreuna dintre categoriile numite în regulament. La majoritatea firmelor mici încape pe o pagină.
Articolul 4, modificat prin Omnibus, cere măsuri care să sprijine dezvoltarea cunoștințelor despre AI ale personalului și ale celor care folosesc sistemele în numele firmei, în funcție de pregătire și de context. Nu cere garantarea unui anumit nivel pentru fiecare persoană. Aceasta este o parafrază a textului englez, nu un citat din versiunea oficială română. Inventarul vă arată cine are nevoie de instruire și despre ce. Un ghid scurt și evidența parcurgerii lui pot fi un punct de plecare, dar măsurile trebuie potrivite riscurilor și utilizării reale.
Inventarul arată și cazurile în care articolul 50 îi privește pe implementatori: recunoașterea emoțiilor sau clasificarea biometrică (alineatul 3), deepfake-urile de imagine, audio sau video (alineatul 4) și textul generat cu AI publicat pentru a informa publicul despre chestiuni de interes public, cu excepția textului verificat de un om, pentru care cineva își asumă responsabilitatea editorială.
La unele firme, inventarul scoate la iveală muncă reală.
Angajare, credit și alte utilizări din anexa III. Anexa III enumeră, printre altele, sistemele AI folosite pentru analizarea și filtrarea candidaturilor și evaluarea candidaților. Un sistem care ierarhizează sau respinge candidați pe baza evaluării lor este exemplul relevant de risc ridicat. Un instrument care doar reformatează CV-uri nu este automat echivalent. Articolul 6 alineatul (3) permite excluderea unor sisteme din anexa III dacă nu prezintă un risc semnificativ pentru sănătate, siguranță sau drepturi fundamentale, inclusiv prin faptul că nu influențează semnificativ deciziile, și îndeplinesc una dintre condiții: sarcină procedurală restrânsă, îmbunătățirea unei activități umane încheiate, detectarea tiparelor fără înlocuirea ori influențarea evaluării umane încheiate fără o verificare adecvată sau o sarcină pregătitoare. Sistemele din anexa III care creează profiluri ale persoanelor rămân cu risc ridicat. Furnizorul care invocă excluderea trebuie să documenteze evaluarea și să înregistreze sistemul potrivit alineatului (4). De la 2 decembrie 2027, articolul 26 le cere implementatorilor sistemelor care rămân încadrate cu risc ridicat să folosească sistemul conform instrucțiunilor, să încredințeze supravegherea umană unor oameni cu competența și autoritatea necesare, să urmărească funcționarea sistemului, să păstreze cel puțin șase luni jurnalele pe care le controlează și să-i informeze pe reprezentanții angajaților și pe angajații vizați înainte de a-l folosi la locul de muncă. Asta chiar înseamnă un program de conformitate, deși unul cu limite clare.
Furnizor fără să vreți. Potrivit articolului 25, implementatorul care își pune numele pe un sistem cu risc ridicat, îl modifică substanțial astfel încât rămâne cu risc ridicat sau schimbă scopul unui sistem general astfel încât acesta devine cu risc ridicat preia obligațiile furnizorului. O firmă de software care adaugă în produsul ei de resurse umane o ierarhizare automată a candidaților se află exact în situația aceasta. De aceea inventarul trebuie să noteze scopul: scopul decide clasificarea.
Practicile interzise. Rareori privesc o firmă obișnuită, dar se aplică deja și au cele mai mari amenzi: până la 35 de milioane de euro sau 7% din cifra de afaceri mondială.
Protecția datelor. Articolul 2 alineatul (7) spune că regulamentul nu afectează GDPR. Un chatbot care primește date ale clienților ridică mai întâi întrebări de protecție a datelor, iar inventarul își are locul lângă evidențele pe care le țineți deja pentru GDPR.
Argumentele pentru a cheltui devreme sunt serioase. Amenzile pentru încălcarea articolului 50 sau a obligațiilor implementatorilor pot ajunge la 15 milioane de euro sau 3% din cifra de afaceri mondială, oricare este mai mare. Aplicarea diferă de la un stat la altul și nimeni nu poate spune ce cazuri vor da tonul. Clienții mari trimit chestionare de achiziții care cer politici de guvernanță AI, iar furnizorul mic fără răspunsuri pierde contractul.
Fiecare argument este corect, dar niciunul nu schimbă ordinea muncii. Pentru IMM-uri, articolul 99 alineatul (6) plafonează fiecare amendă la valoarea cea mai mică dintre cele două, nu la cea mai mare: la o cifră de afaceri de 2 milioane de euro, 3% înseamnă 60.000 de euro. Amenda efectivă depinde de încălcare și de factorii prevăzuți de lege. Identificați și îndepliniți obligațiile aplicabile înainte să cumpărați un program generic. La un chestionar de achiziții răspundeți cu inventarul concret al sistemelor, evaluarea rolului firmei, măsurile de instruire și controalele de transparență.
Un chestionar de achiziții se răspunde mai bine cu inventarul concret: sistemele, rolurile, măsurile de instruire și controalele de transparență. Nu presupuneți că eventualele întârzieri ale aplicării la nivel național suspendă obligațiile regulamentului.
Acolo unde un buget de conformitate se justifică, inventarul îl face eficient, pentru că îi arată consultantului ce sisteme au nevoie de atenție.
Scrieți întâi lista, apoi verificați obligațiile pentru fiecare sistem. O firmă care folosește instrumente obișnuite și una care furnizează un chatbot generativ au sarcini diferite. Furnizorul chatbotului trebuie să verifice informarea și marcarea automată a conținutului, implementarea tehnică și eventualele excepții. Utilizările în angajare, credit și educație cer o evaluare documentată a clasificării; inventarul este începutul analizei, nu dovada conformității complete.
Oferta noastră de agenți AI prevede descrierea fluxurilor de date și a limitelor aprobării umane înainte de dezvoltare. Pentru un sistem care interacționează cu oamenii, proiectul trebuie să stabilească explicit rolul firmei, clasificarea și controalele de transparență aplicabile.
UniSuper este un fond de pensii din Australia. La începutul lui mai 2024, peste o jumătate de milion de membri ai fondului au rămas mai mult de o săptămână fără acces la conturi (The Guardian, 9 mai 2024). Pe 8 mai, directorul general al UniSuper și directorul general al Google Cloud, Thomas Kurian, au publicat o declarație comună: o configurare greșită, făcută din neatenție la crearea serviciilor de cloud privat, a dus în cele din urmă la ștergerea abonamentului Private Cloud al UniSuper.
Partea care îi privește pe toți ceilalți vine imediat după. UniSuper avea datele duplicate în două zone geografice, tocmai ca protecție împotriva întreruperilor și a pierderilor, dar ștergerea abonamentului le-a șters în ambele. Fondul a scăpat pentru că avea backupuri la un alt furnizor, care, potrivit declarației, au redus pierderea de date și au ajutat mult la restaurare. The Register a rezumat situația în aceeași zi: fără backupurile de la celălalt furnizor, lucrurile ar fi putut fi mult mai grave.
Două săptămâni mai târziu, Google și-a publicat propria analiză (pagina Google indică 24 mai 2024; prefața UniSuper datează informațiile suplimentare la 25 mai). La începutul lui 2023, operatorii Google au creat unul dintre cloudurile private Google Cloud VMware Engine ale UniSuper cu un instrument intern și au lăsat necompletat un parametru. Sistemul l-a completat cu o valoare implicită pe care nu o cunoștea nimeni: o durată fixă de un an, urmată de ștergere automată. După un an, cloudul privat a fost șters, fără nicio notificare către client, pentru că ștergerea nu pornise de la o cerere a clientului.
Varianta Google e mai îngustă decât titlurile care vorbeau despre un cont șters. Analiza descrie un singur client, o singură regiune și unul dintre mai multe clouduri private ale clientului, întins pe două zone. Contul Google, proiectele și celelalte clouduri private ale clientului nu au fost atinse. Backupurile din Google Cloud Storage din aceeași regiune nu au fost afectate de ștergere și, împreună cu un software de backup terț, au contat mult la restaurare.
Povestea e deci mai puțin spectaculoasă decât „Google a șters un fond de pensii” (merită observată diferența dintre „două zone geografice” din declarația comună și „două zone” din analiza Google), dar mai instructivă. Ștergerea a urmat granița unui singur abonament. Tot ce era în interiorul ei a dispărut, cu ambele copii, pentru că replicarea copiază o ștergere la fel de fidel cum copiază datele. A rămas ce se afla în afara ei: stocarea dintr-un alt serviciu și backupurile ținute la alt furnizor.
Clientul nu și-a ales această graniță. A ales-o un câmp lăsat gol într-un instrument intern. Nu aveți cum să știți dinainte unde va cădea granița următorului incident, iar acesta e argumentul pentru a ține cel puțin o copie acolo unde niciun eveniment de la furnizor nu poate ajunge.
Ajută să separați felurile în care dispar efectiv datele, pentru că fiecare cere altă protecție.
Cade o zonă sau o regiune. O pană de curent, de răcire sau de rețea scoate din funcțiune o locație. Replicarea în mai multe zone sau regiuni rezolvă bine problema; pentru asta a fost gândită redundanța din cloud.
Furnizorul vă șterge resursele. O ștergere ca la UniSuper, un cont suspendat, o problemă de facturare. În discuția de pe Hacker News despre incident, un utilizator povestea că proiectele Google Cloud ale unei firme s-au oprit în câteva minute după ce departamentul de resurse umane a șters contul unui fost angajat, cont de care era legat profilul de plată. E o întâmplare relatată, nu o statistică, dar arată cât de banal poate fi declanșatorul. Replicarea la același furnizor nu ajută aici. Singura protecție e o copie într-un alt cont, cu facturare și date de acces separate, ideal la alt furnizor.
Greșește chiar echipa firmei. O migrare șterge un tabel, un script golește un bucket de stocare, cineva cu drepturi de administrator cade într-o capcană de phishing. Replicarea copiază paguba în câteva secunde. Protecția sunt copiile cu versiuni, păstrate câteva săptămâni, cu date de acces pe care sistemul de producție nu le are, astfel încât ce șterge producția să nu poată șterge și backupurile.
Pentru cele mai multe firme mici, al treilea caz e, după părerea noastră, mult mai probabil decât al doilea. Vestea bună este că protecția pentru al doilea caz acoperă și mare parte din al treilea, dacă e configurată cum trebuie.
Nimic din toate acestea nu cere bugetul UniSuper. Pentru o aplicație web obișnuită, stabiliți întâi pierderea maximă acceptabilă de date (RPO) și timpul acceptabil până la reluarea serviciului (RTO). Pașii următori sunt un exemplu, nu un minim universal:
Dacă un al doilea furnizor e deocamdată prea mult, un cont separat la același furnizor e un prim pas rezonabil. AWS, de exemplu, documentează copierea backupurilor într-un alt cont din aceeași organizație, astfel încât un backup șters într-un cont să poată fi recuperat din celălalt. Asta acoperă propriile greșeli și un cont compromis. Nu acoperă situația în care furnizorul acționează asupra întregii organizații.
Testul de restaurare îl face inginerul, colaboratorul sau firma care administrează sistemul. Rezultatul îi aparține firmei. Asta înseamnă că firma, nu un programator cu adresa lui personală de e-mail, deține contul de backup, că raportul de restaurare ajunge la cineva care poate decide și că testul e trecut în calendar, nu lăsat la bunăvoința cuiva. Un backup pe care nu l-a restaurat nimeni e doar o speranță. E aceeași idee ca în articolul Software needs an owner (în engleză): treaba nu e gata când un instrument e configurat, ci când cineva răspunde de rezultat.
Dacă plătiți pentru mentenanță software, cereți să vedeți ultimul raport de restaurare. Dacă nu există, de aici începeți.
Chiar analiza Google este cel mai bun contraargument. Ea spune că a fost primul incident de acest fel, că nu e o problemă sistemică și că backupurile UniSuper din Google Cloud Storage, din aceeași regiune, au supraviețuit și au fost folosite la recuperare. Din acest punct de vedere, o configurare bine făcută la un singur furnizor ar fi fost suficientă, iar un al doilea furnizor aduce costuri, încă un set de date de acces și de chei de criptare de protejat, taxe de transfer al datelor și încă un sistem de monitorizat.
O parte din obiecție e corectă. Riscul e mic, iar un al doilea furnizor configurat neglijent, cu cheile ținute lângă producție sau cu o restaurare pe care n-a încercat-o nimeni, adaugă muncă fără să adauge siguranță. Numai că obiecția se sprijină pe ce știm abia acum despre locul în care s-a oprit ștergerea. O copie independentă există tocmai ca să nu depindeți de faptul că următorul incident va avea aceeași întindere ca ultimul. Iar pentru o bază de date mică, un export zilnic criptat la alt furnizor costă probabil mult mai puțin decât o singură săptămână fără acces la date.
Recomandarea se potrivește mai puțin în trei situații.
Incidentul UniSuper e ținut minte mai ales ca greșeala Google, iar Google a schimbat într-adevăr instrumentul și valoarea implicită care l-au provocat. Lecția care rămâne ține însă de decizia UniSuper, luată cu mult înainte de mai 2024, de a păstra backupuri în altă parte. Redundanța vă ține sistemul în funcțiune când cade o locație. O copie testată, în afara furnizorului, vă permite să vă recuperați datele când furnizorul, un coleg sau un script șterge chiar lucrul care era redundant.
La doi ani și jumătate distanță, scăderea prețului e partea care merită ținută minte din acea săptămână, pentru că a schimbat socoteala. Pentru o firmă mică sau mijlocie care vrea să integreze un model AI, precum cel din ChatGPT, într-o aplicație existentă, factura pentru model decide rar dacă funcția merită banii. Decid integrarea, testarea, limitele puse modelului și mentenanța. Acolo trebuie să meargă bugetul.
GPT-4o nu a fost o reducere izolată. Două luni mai târziu, OpenAI a lansat GPT-4o mini, care, după calculul lui Simon Willison, era de 33 de ori mai ieftin decât GPT-4o la intrare și de 25 de ori la ieșire. În august, o nouă versiune, gpt-4o-2024-08-06, a coborât prețul la 2,50 dolari pe milion de tokeni de intrare și 10 dolari la ieșire, adică jumătate din prețul de intrare al versiunii din mai.
Acestea sunt și astăzi prețurile de listă pentru GPT-4o și GPT-4o mini pe pagina de prețuri OpenAI, iar cel mai ieftin model din tabelul principal de la începutul paginii, gpt-6-luna, costă 0,10 dolari pe milion de tokeni de intrare și 0,50 dolari la ieșire.
Să luăm o funcție obișnuită: aplicația citește o cerere de la un client, de circa 2.000 de tokeni, și pregătește un răspuns de 300 de tokeni, pe care îl verifică un om. Presupunem 10.000 de cereri pe lună. Calculul de mai jos folosește doar prețurile de listă, fără reducerile pentru cache sau pentru procesarea în batch.
| Model și preț | Intrare pe lună | Ieșire pe lună | Total pe lună |
|---|---|---|---|
| GPT-4o, mai 2024 (5 $ / 15 $) | 100 $ | 45 $ | 145 $ |
| GPT-4o, august 2024 (2,50 $ / 10 $) | 50 $ | 30 $ | 80 $ |
| GPT-4o mini (0,15 $ / 0,60 $) | 3 $ | 1,80 $ | 4,80 $ |
Cifrele sunt ilustrative și nu provin dintr-un sistem real. Contează ordinul de mărime. La aceste prețuri, modelul costă între câțiva dolari și aproximativ 150 de dolari pe lună. Comparați suma cu cât vă costă o săptămână de lucru a unui programator și vedeți singuri unde se duc banii.
Pentru un proprietar de firmă, împărțirea utilă e între ce crește odată cu utilizarea și ce nu crește.
Costuri care cresc odată cu utilizarea: tokenii, găzduirea părților care apelează modelul și timpul în care oamenii dumneavoastră verifică ciornele. Dintre acestea, doar primul a scăzut puternic în 2024.
Costuri fixe de dezvoltare: legarea modelului de datele și de aplicațiile firmei, regulile despre ce are și ce nu are voie să facă, ecranul în care un om aprobă rezultatul, testarea pe exemple din trecut, jurnalul cu ce a făcut modelul și tratarea situațiilor în care greșește, răspunde greu sau nu e disponibil.
Costuri recurente de dezvoltare: tot ce e mai sus trebuie ținut în funcțiune în timp ce furnizorul schimbă modele, prețuri și API-uri.
Liniile fixe și recurente nu s-au ieftinit odată cu tokenii. Un prompt care redactează răspunsuri se scrie într-un weekend. Proiectul propriu-zis înseamnă ca răspunsul să citeze lista de prețuri actuală, să nu promită niciodată un termen de livrare pe care depozitul nu îl poate respecta și să ajungă la o persoană anume înainte să ajungă la client.
Cea mai bună dovadă pentru costul de mentenanță e chiar pagina de modele retrase a OpenAI (în engleză). Pentru versiunea originală gpt-4o-2024-05-13, modelul lansat în acea săptămână, retragerea a fost anunțată pe 22 aprilie 2026, iar accesul a fost oprit pe 23 octombrie 2026. Pe 14 octombrie 2026, OpenAI le-a anunțat programatorilor că versiunile ulterioare de GPT-4o, GPT-4o mini și GPT-4.1 vor fi scoase din API pe 14 ianuarie 2027.
Așadar, o funcție construită pe GPT-4o în mai 2024 a ajuns deja la un model schimbat sau retras. Dacă funcția este încă folosită și depinde de versiunile vizate de anunț, va avea nevoie de un model înlocuitor până la termen. Fiecare mutare înseamnă lucru de inginerie: noul model rulează pe aceleași exemple din trecut, răspunsurile se compară, prompturile și limitele se ajustează, apoi urmează lansarea. O echipă care nu și-a construit de la început un set de exemple de test face comparația de mână sau o sare și află de la clienți.
De aceea cred că bugetul trebuie pus în testare și în integrare. Pariul că tokenii se vor ieftini a fost corect. Pariul că integrarea se va ieftini sau că nu va mai trebui atinsă nu a fost.
A scăzut prețul pe token pentru un anumit nivel de capacitate. Factura totală pentru tokeni nu a urmat mereu aceeași direcție.
Modelele de raționament generează tokeni interni înainte să răspundă, iar documentația OpenAI spune că acești tokeni de raționament sunt facturați ca tokeni de ieșire (în engleză): de la câteva sute la zeci de mii pe cerere, după complexitatea problemei. Un agent AI care apelează unelte în buclă retrimite modelului, la fiecare pas, conversația din ce în ce mai lungă. Nici vârful gamei nu s-a ieftinit: gpt-6-astra, primul în tabelul de prețuri de astăzi, costă 10 dolari pe milion de tokeni de intrare și 50 de dolari la ieșire, mult peste prețul de lansare al GPT-4o, iar modelele „pro” costă și mai mult.
Obiecția e întemeiată și schimbă sfatul într-un singur punct. Costul de utilizare nu mai e o cifră pe care o estimați o dată și o uitați. Trebuie măsurat pe traficul real și plafonat în cod, de exemplu cu o limită de tokeni de ieșire pe cerere și cu o alertă pentru bugetul lunar. Teza rămâne însă în picioare, ba chiar se întărește. Alegerea celui mai ieftin model care trece exemplele de test, limitarea pașilor pe care îi poate face un agent și urmărirea facturii sunt tot muncă de inginerie. Facturile mari pot veni și din muncă dificilă, valoroasă sau din volum legitim; suma singură nu arată calitatea ingineriei.
Concluzia privește firmele care adaugă AI la o sarcină bine definită, cu un volum moderat. Nu se aplică în trei situații.
Volum foarte mare. Dacă procesați milioane de documente pe lună, factura pentru tokeni e o cheltuială reală, iar alegerea modelului, cache-ul și prețurile pentru batch merită aceeași atenție ca restul codului.
Agenți care lucrează mult timp și raționament intens. O funcție care lasă modelul să „gândească” mult sau să facă multe apeluri de unelte pentru fiecare cerere poate costa câțiva dolari pe sarcină. Măsurați înainte să promiteți un preț propriilor clienți.
Când răspunsul corect e fără AI. Dacă sarcina e o regulă fixă, un formular sau un raport, o automatizare simplă costă mai puțin și nu are niciun model de migrat. Un furnizor serios vă spune asta înainte să vă dea o ofertă pentru o funcție AI.
Cereți furnizorului să separe cele trei linii: costul lunar estimat pentru model la volumul dumneavoastră, construcția inițială și ce presupune întreținerea. Întrebați pe ce exemple din trecut va fi testată funcția, cine aprobă rezultatul și ce se întâmplă când furnizorul modelului îl retrage. Dacă oferta vorbește mai ales despre model, se uită la partea cea mai ieftină a lucrării.
Oferta noastră pentru agenții AI și funcțiile AI pornește de la o singură sarcină, descrisă în scris, testată pe exemplele dumneavoastră din trecut, cu un om care aprobă rezultatul și cu costurile de funcționare estimate separat de dezvoltare.
Pe 3 mai 2024, Zeke Gabrielse, fondatorul Keygen, un API pentru licențierea software-ului, a publicat o analiză a propriilor cifre (în engleză). Pornise cu un trial gratuit de 14 zile. Clienții nu reușeau să integreze un API de licențiere în aplicațiile lor în acest interval, așa că a început să ofere prelungiri. În următorii ani, scrie el, majoritatea clienților care au ajuns să plătească ceruseră o prelungire, iar rata de conversie era mai mare în cazul lor.
La început cerea un card înregistrat înainte să prelungească trialul, apoi a renunțat la acest pas pentru că schimbul de mesaje era obositor. După spusele lui, conversia nu a scăzut, deci cardul nu explica diferența.
Cifra care conta era ceea ce el numește „time-to-convert”: zilele de la înscriere până la prima plată. Mediana lui era de 41 de zile. Percentila 90 era de 130 de zile, percentila 95 de 198, iar percentila 99 de 290. Le dădea clienților 14 zile ca să ia o decizie la care clientul plătitor tipic ajungea după șase săptămâni. De fapt, spune el, le cerea să aștepte: până erau gata să citească documentația, până se planifica un proof of concept, până se elibera un programator. Mulți vedeau termenul apropiindu-se, hotărau că nu sunt pregătiți, plecau și nu mai reveneau.
Soluția lui a fost cea de care fondatorii fără finanțare sunt sfătuiți să se ferească: un trial nelimitat, adică un plan gratuit. Gabrielse a raportat o creștere a înscrierilor. Separând clienții care au rămas pe planul gratuit, a constatat că au crescut și înscrierile plătite, că rata de conversie a rămas aceeași și că a dispărut munca manuală cu prelungirile.
Articolul a pornit o discuție lungă pe Hacker News (în engleză) pe 6 mai 2024. Un participant descria o echipă de evaluare a cărei regulă e un minimum de 30 de zile, fără plată și fără funcții tăiate, și pentru care chiar și 30 de zile sunt puține ca să pună sistemul în funcțiune cu propriile date de test. Gabrielse a precizat în discuție că planul lui gratuit are limite, de exemplu 100 de utilizatori activi și 2.000 de cereri API pe zi, deci nu poate susține o aplicație în producție. Presiunea de a plăti apare după ce clientul a făcut efectiv integrarea, nu înainte.
La doi ani distanță, pagina de prețuri Keygen (în engleză) descrie în continuare planul Dev ca pe un plan gratuit limitat, gândit pentru „faza de integrare și dezvoltare”, cu limite stricte care întorc o eroare când sunt atinse, și oferă la cerere un trial de 30 de zile pentru varianta Enterprise găzduită de client. Soluția a rezistat.
Dezbaterea obișnuită despre durata trialului compară rata de conversie medie pentru 14 și 30 de zile, pe multe firme la un loc. Comparația ascunde tocmai variabila care decide răspunsul: cât îi ia clientului firmei să ajungă în punctul în care poate răspunde la întrebarea „merită să plătesc pentru asta?”. Pentru o aplicație de notițe poate fi o după-amiază. Pentru un API care trebuie legat de procesul de livrare al aplicației sau pentru un program de back-office în care trebuie importate facturile pe un an, pot fi săptămâni.
Un trial care se termină înainte de acel punct nu testează produsul. Testează dacă cumpărătorul a avut, întâmplător, două săptămâni libere. Clienții pe care îi pierde nu sunt neapărat nepotriviți: mulți sunt firme ocupate, cu o nevoie reală și cu alte proiecte la rând.
Așadar durata perioadei de probă e un rezultat, nu un punct de plecare. Măsurați cât le ia clienților care reușesc să ajungă la primul rezultat real și stabiliți durata în funcție de asta. Apoi vedeți cu ce se umplu acele zile.
Aici teza cere atenție, pentru că soluția Keygen nu a fost un onboarding mai bun, ci renunțarea la termen. Ambele răspunsuri sunt corecte, pentru părți diferite ale întârzierii.
Timpul de lucru e cel pe care clientul îl petrece efectiv cu produsul: citește documentația, creează conturi, potrivește câmpurile, scrie prima integrare, importă datele. Aceasta e problema pe care trebuie să o rezolvați. Date de exemplu, un exemplu funcțional în limbajul de programare al clientului, un import care acceptă tabelul pe care îl are deja, o discuție de configurare pentru pasul la care se blochează toată lumea: fiecare scurtează drumul, iar un termen mai lung nu rezolvă niciuna dintre aceste probleme. Dacă un client care se apucă serios de treabă are nevoie de trei săptămâni de muncă până să vadă ceva util, un trial de 30 de zile îi dă doar mai mult timp să se împotmolească.
Timpul de așteptare e intervalul dintre înscriere și momentul în care clientul poate începe: programatorul e pe alt proiect, cel care aprobă bugetul e în concediu, cei de la securitate vor un chestionar completat. Nu îl puteți scurta prin onboarding. Un trial cu termen fix îl penalizează, exact cum a descris Gabrielse. Un plan gratuit cu limite de utilizare sau un trial care începe să curgă de la prima utilizare reală se potrivesc mai bine.
Cele mai multe produse le au pe amândouă. Întrebarea practică e care dintre ele cântărește mai mult la clienții firmei.
Nu aveți nevoie de o platformă de analiză. Articolul lui Gabrielse include o interogare Stripe Sigma pentru timpul până la plată. Mai util în completare e timpul până la primul rezultat real, care cere o singură decizie: ce eveniment arată că clientul a obținut ceva concret. Pentru un API de licențiere poate fi prima licență validată din aplicația clientului; pentru un program de facturare, prima factură trimisă unui client adevărat.
Dacă înregistrați evenimentele în PostgreSQL, o interogare de acest fel vă dă distribuția (numele tabelelor și al evenimentului sunt doar exemple):
SELECT
percentile_cont(0.5) WITHIN GROUP (ORDER BY days) AS p50_days,
percentile_cont(0.9) WITHIN GROUP (ORDER BY days) AS p90_days
FROM (
SELECT a.id,
EXTRACT(EPOCH FROM MIN(e.created_at) - a.created_at) / 86400 AS days
FROM accounts a
JOIN events e ON e.account_id = a.id
WHERE e.name = 'first_production_use'
AND a.created_at > now() - interval '1 year'
GROUP BY a.id, a.created_at
) t;
Două precauții. Interogarea numără doar conturile care au ajuns la eveniment, deci descrie clienții care au reușit, nu pe cei pierduți din cauza termenului. Înregistrați și prima acțiune semnificativă după înscriere. Intervalul până la acea acțiune și cel de la acțiune la primul rezultat sunt indicii despre așteptare și evaluare, măsurate în timp calendaristic. Ambele pot include pauze, weekenduri și alte așteptări. Pentru a măsura munca efectivă aveți nevoie de date despre sesiuni sau activitate ori de discuții cu clienții; momentele înregistrate nu o separă singure.
Trialurile scurte au motivele lor. Kyle Poyar descrie compromisul în ghidul său despre reverse trials (în engleză), publicat în Growth Unhinged: produsele cu trial gratuit au adesea o conversie de la gratuit la plătit de două sau trei ori mai mare decât cele freemium, pentru că termenul forțează o decizie, și convertesc mai repede, cu un timp median până la cumpărare care „poate fi de 14 zile”, față de 60 sau 90 la un produs freemium. Pentru o firmă mică ce plătește pentru achiziția de clienți, momentul în care intră banii contează.
Există și obiecția din partea vânzărilor, ridicată în discuția de pe Hacker News: clienții care cer la nesfârșit prelungiri adesea doar se uită prin vitrină, iar trialurile lungi îi lasă să consume suport fără intenția de a cumpăra. Un alt participant a observat un efect de selecție în prima constatare a lui Gabrielse: cei care cer o prelungire sunt deja cei interesați. El a răspuns că afirmația se referea la creșterea conversiei totale atunci când a oferit prelungiri, ceea ce e corect, dar rămâne relatarea unei singure firme, nu un experiment controlat.
Ambele obiecții sunt reale. Niciuna nu justifică însă un termen arbitrar de 14 zile. Un termen creează urgență doar dacă clientul putea lua o decizie înainte de el. Chiar trialul invers descris de Poyar, cu toate funcțiile pentru o perioadă limitată și apoi trecerea pe un plan gratuit, e o metodă de a păstra urgența fără a-l pierde pe cumpărătorul mai lent.
Dacă produsul aduce valoare clientului încă din prima sesiune, un trial scurt e în regulă, iar un plan gratuit poate însemna doar venit pierdut. Dacă utilizarea gratuită vă costă bani reali, de exemplu putere de calcul sau suport oferit de oameni, un plan nelimitat are nevoie de limite ferme, altfel devine o subvenție. Iar pentru software vândut câtorva firme mai mari, trialul în regim self-service poate fi cu totul nepotrivit. Un pilot asistat, cu funcționalitățile agreate, o persoană de contact de fiecare parte, criterii de reușită scrise înainte de început și o dată de încheiere legată de aceste criterii, e adesea mai bun pentru ambele părți decât orice termen fix. Asta e valabil mai ales când configurarea implică datele clientului sau un alt sistem, genul de muncă pe care îl presupune de obicei dezvoltarea de software la comandă. Dacă încă decideți ce ar trebui să conțină prima versiune, articolul MVP vs prototype (în engleză) tratează această alegere anterioară.
Nu alegeți 14 sau 30 de zile pentru că așa spune un studiu comparativ. Măsurați cât le ia clienților plătitori să ajungă la primul rezultat real, scurtați partea de lucru printr-un onboarding mai bun și nu lăsați termenul să penalizeze partea de așteptare. Perioada de probă e destul de lungă atunci când un client care chiar vrea produsul poate lua o decizie reală înainte să se termine.
După doi ani și jumătate, lecția utilă privește locul în care se află răspunsul, mai mult decât intențiile Slack. Cazurile Slack și Zoom arată de ce trebuie citite împreună contractul și politicile la care trimite. Două cazuri nu arată cât de des este activată implicit antrenarea în aplicațiile SaaS. De aceea, condițiile privind folosirea datelor pentru AI trebuie verificate când alegeți furnizorul. Cereți răspunsul în scris și aflați dinainte cum ați pleca. Un e-mail de opt-out este o cerere a cărei executare nu o puteți vedea, așa că nu ține locul unui mecanism de control.
Pe 16 mai 2024, cineva a publicat pe Hacker News doar un link către principiile de confidențialitate ale Slack, cu titlul „Slack AI Training with Customer Data”. Pagina, așa cum a fost arhivată în acea zi, spunea că, pentru a dezvolta modele AI și ML, sistemele Slack analizează „Customer Data” (mesaje, conținut și fișiere), dar și alte informații, inclusiv date de utilizare. Ca să fie exclus din modelele globale ale Slack, clientul trebuia să ceară proprietarilor organizației sau ai workspace-ului să scrie echipei de suport la feedback@slack.com, cu un anumit subiect al mesajului.
A doua zi, TechCrunch scria că, potrivit Internet Archive, condițiile se aplicau cel puțin din septembrie 2023. Adam Engst, de la TidBITS, a găsit ulterior și o versiune din octombrie 2020 a documentului, cu titlul „Privacy principles: search, learning and intelligence”, scrisă înainte de valul AI generativ.
Slack a răspuns pe 17 mai printr-un articol pe blog, în care recunoștea că formulările puteau crea neînțelegeri. Potrivit companiei, modelele clasice de machine learning, folosite din 2017 pentru ordonarea rezultatelor la căutare, recomandări de canale și emoji și completare automată, lucrează cu date agregate, fără elemente de identificare, și nu au acces la conținutul mesajelor. Modelele lingvistice mari din Slack AI, suplimentul plătit, nu erau antrenate pe datele clienților. Iar fraza cea mai importantă pentru acest articol: workspace-urile nu sunt excluse în mod implicit („workspaces are not opted out by default”).
Cel mai bun argument împotriva indignării a apărut chiar atunci și este solid. În articolul de pe TidBITS, Engst susținea că oamenii au reacționat la un link și la o captură de ecran, fără să citească documentul. Într-o corectură adăugată în comentarii, a recunoscut că citise mai întâi versiunea revizuită de Slack pe 18 mai. Chiar și așa, versiunea care a pornit scandalul descria sugestii de canale, ordonarea rezultatelor la căutare, completare automată și sugestii de emoji, niciuna generativă, și preciza deja că modelele globale nu sunt antrenate astfel încât să poată învăța, memora sau reproduce date ale clienților. Explicația lui: nimeni nu construise o setare pentru că nimeni nu se aștepta ca vreun client să vrea să renunțe la sugestiile de emoji.
Probabil că Engst avea dreptate în privința intențiilor Slack. Totuși, asta nu răspunde la întrebarea unei firme, din trei motive.
Primul: protecția era o descriere scrisă de furnizor. „Date agregate, fără elemente de identificare” sau „nu avem acces la conținut” sunt afirmații despre o implementare pe care nu o puteți inspecta. Pot fi adevărate, dar trebuie să le acceptați pe încredere.
Al doilea: domeniul s-a lărgit fără ca clientul să facă ceva. Pagina care în 2020 vorbea despre sugestii de emoji devenise, în 2024, locul unde oamenii căutau ce face un produs AI cu mesajele lor. TechCrunch îl cita pe un inginer Slack care admitea că pagina trebuia actualizată ca să arate cum se aplică principiile la Slack AI. Condițiile rămăseseră aceleași, dar ce trebuiau ele să acopere crescuse.
Al treilea: ieșirea era slabă. Doar anumiți proprietari puteau cere excluderea, prin e-mail, iar clientul afla că cererea a fost executată când primea răspuns de la Slack. Un utilizator Hacker News a publicat răspunsul primit: o confirmare, urmată de același paragraf pe care Slack îl trimisese și presei.
Cu nouă luni înainte, Zoom trecuse prin același ciclu. În august 2023, The Record scria că termenii Zoom, modificați, se pare, în martie, îi dădeau companiei drepturi largi asupra datelor generate de serviciu, inclusiv pentru antrenarea AI. Zoom a adăugat apoi, cu caractere îngroșate, o frază potrivit căreia nu va folosi conținutul audio, video sau din chat pentru antrenarea modelelor fără consimțământul clientului. Un jurist citat în articol, David Brody, de la Lawyers' Committee for Civil Rights Under Law, observa că termenii nu spuneau cum ar arăta acel consimțământ.
În ambele cazuri, lucrurile s-au petrecut la fel: condițiile stăteau pe o pagină controlată de furnizor, publicul le-a citit abia după ce cineva le-a făcut cunoscute, iar remedierea a fost o frază revizuită pe aceeași pagină.
Pagina cu principiile de confidențialitate ale Slack, citită pe 8 noiembrie 2026, arată două schimbări și un lucru rămas la fel. Acum, Slack spune că nu dezvoltă modele de AI generativ cu datele clienților și că nu le va folosi pentru antrenarea acestor modele fără consimțământul explicit al clientului (opt-in). Pentru modelele generative, regula a devenit deci opt-in. Modelele predictive au rămas pe opt-out, iar calea documentată de ieșire este tot un e-mail trimis de un proprietar al workspace-ului la feedback@slack.com.
Această împărțire, opt-in pentru antrenarea generativă și opt-out pentru modelele predictive globale descrise aici, este un compromis rezonabil pentru un furnizor. Este însă și distincția despre care majoritatea cumpărătorilor nu știu să întrebe.
Majoritatea sfaturilor pe această temă sunt scrise pentru firme care negociază contracte enterprise. O firmă de douăsprezece persoane cu un abonament Slack Pro nu negociază nimic. Poate doar să aleagă între furnizori după ce publică aceștia. Pentru fiecare aplicație în care țineți date ale clienților sau ale angajaților, notați răspunsurile la șase întrebări.
Răspunsurile rareori decid singure alegerea. Vă arată ce ați acceptat și ce furnizor e dispus să vă spună lucrurile în scris.
Verificarea merită timpul pentru aplicațiile în care țineți conversații cu clienții, contracte, date medicale sau financiare ori cod sursă. Nu merită pentru un instrument care vede doar site-ul public al firmei. Dacă aveți deja un contract enterprise negociat, contractul are prioritate și pagina de politici contează mai puțin, deși merită verificat că spun același lucru. Uneori, toți furnizorii dintr-o categorie au condiții asemănătoare, iar verificarea doar confirmă că nu aveți o variantă mai bună. Și asta e util: aflați ce nu trebuie să puneți în aplicația respectivă.
E-mailul de opt-out trebuie totuși trimis. E mai bun decât nimic, iar la Slack este singura cale documentată. Doar nu îl considerați un mecanism de control. Un mecanism de control este ceva ce puteți verifica oricând că funcționează. Pentru sistemele unde aveți nevoie de această verificare, variantele oneste sunt un contract cu clauze reale sau un software dezvoltat la comandă, pe care îl dețineți și îl administrați, ceea ce vă poate da mai mult control asupra fluxurilor de date. Proprietatea sau găzduirea proprie nu împiedică singure antrenarea de către furnizori externi: verificați condițiile furnizorilor de modele, integrările, telemetria și controalele instalate.
La Google I/O, pe 14 mai 2024, echipa Android a anunțat suportul oficial pentru Kotlin Multiplatform (KMP). Anunțul era mai precis decât titlurile care au urmat. Google a spus că se concentrează pe partajarea logicii de business, adică a părților cele mai puțin legate de interfață, pentru că acolo văzuse cel mai mare câștig pentru dezvoltatorii Android: nu mai trebuie să întrețină copii duplicate ale aceluiași cod.
Anunțul venea cu dovezi, nu doar cu o declarație de presă. Aplicația Google Docs pentru Android, iOS și web folosea KMP pentru logica de business comună, iar echipa Workspace numea KMP direcția arhitecturii sale pentru mai multe platforme. Mai multe biblioteci Jetpack primiseră suport KMP: Annotations, Collections și DataStore în versiuni stabile, Room, Lifecycle și ViewModels în alpha. Android Gradle Plugin a primit suport oficial pentru ținte KMP, iar inginerii Android au raportat o îmbunătățire de 18% a performanței la rulare în benchmarkurile compilatorului Kotlin/Native.
Tehnologia nu era nouă. JetBrains declarase Kotlin Multiplatform stabil în Kotlin 1.9.20 în noiembrie 2023. Atunci, Compose Multiplatform, varianta care permite și o interfață comună, era încă în alpha pe iOS. Ce s-a schimbat în mai 2024 a fost riscul. O echipă care alegea KMP nu mai depindea doar de un singur furnizor de unelte. Proprietarul platformei Android își pusese în spatele abordării propria aplicație importantă și propriile biblioteci, și le pusese anume în spatele stratului de logică.
Gândiți-vă la ce dublează, de fapt, două aplicații native fără cod comun. Fiecare regulă despre bani, eligibilitate, date calendaristice și stări se scrie o dată în Kotlin și o dată în Swift, de oameni diferiți, de obicei în momente diferite. Un exemplu mic din genul de cod care își are locul într-un modul comun:
Exemplul ilustrează doar rotunjirea, nu o funcție completă de calcul al prețului. Presupune date deja validate: prețuri și cantități nenegative, fiecare produs și suma lor în limitele tipului Long, iar gross * discountPercent tot în aceste limite. Codul verifică doar intervalul reducerii. În producție, aceste limite trebuie impuse înainte de apel.
// commonMain: compiled for Android and for iOS
data class OrderLine(val unitPriceCents: Long, val quantity: Int)
fun orderTotalCents(lines: List<OrderLine>, discountPercent: Int): Long {
require(discountPercent in 0..100) { "Discount must be between 0 and 100" }
val gross = lines.sumOf { it.unitPriceCents * it.quantity }
return gross - gross * discountPercent / 100
}
Împărțirea întreagă de la final aruncă restul, așa că reducerea se rotunjește în jos, iar clientul plătește fracțiunea de ban în plus. Aceasta e o decizie de business. Scrisă de două ori, se ia de două ori, și nimic nu garantează că versiunea din Swift o ia la fel. Adăugați reducerile cumulate, TVA-ul, fusurile orare, regulile de reîncercare pentru operațiile făcute fără conexiune și rezolvarea conflictelor când două dispozitive modifică aceeași înregistrare. Diferențele acestea nu blochează aplicația. Apar ca un tichet la suport în care un client spune că aplicația de iPhone i-a calculat altă sumă sau ca o eroare de sincronizare care apare doar când un utilizator de Android și unul de iOS folosesc același cont. Sunt scumpe pentru că le descoperă târziu clienții.
Un modul comun dă acestei logici o singură implementare și un singur set de teste. Acesta este cel mai puternic argument pentru KMP și ține mai mult de risc decât de viteză.
La interfață lucrurile stau invers. Diferențele dintre platforme nu sunt erori de eliminat. Sunt ce așteaptă utilizatorii: gesturile de navigare, selecția textului, ferestrele sistemului, accesibilitatea și, tot mai mult, aspectul sistemului însuși.
Cel mai clar test a venit după perioada la care se uită acest articol. În iunie 2025, Apple a prezentat Liquid Glass, un nou material de design în iOS 26 și în celelalte sisteme ale sale, pe care l-a numit cea mai amplă actualizare de design software din istoria companiei. Pentru aplicațiile construite cu SwiftUI și UIKit, Apple a livrat API-uri și controale actualizate pentru noul design. Flutter funcționează altfel: potrivit prezentării arhitecturii, are propriile implementări pentru fiecare control de interfață și nu le folosește pe cele ale sistemului. A doua zi după anunțul Apple, echipa Flutter a scris în discuția despre suportul pentru Liquid Glass că nu dezvoltă deocamdată noile elemente de design Apple în biblioteca Cupertino. În iulie 2025 a adăugat că biblioteca Cupertino se mută într-un pachet separat, unde va continua lucrul. În noiembrie 2026, discuția era încă deschisă.
Nu e o critică la adresa ingineriei din Flutter. Desenarea fiecărui control e un compromis asumat, care aduce consecvență între platforme și control asupra randării. Costul este că, atunci când platforma se schimbă, aplicația așteaptă framework-ul. React Native stă la mijloc: documentația spune că, la rulare, creează elementele de interfață native corespunzătoare pe Android și pe iOS, deci e mai puțin expus la problema aceasta. O aplicație KMP cu interfață în SwiftUI e în aceeași situație ca orice aplicație nativă, pentru că interfața este a Apple.
După doi ani, lucrurile s-au mișcat în ambele direcții.
Argumentele pentru a partaja mai mult s-au întărit. JetBrains a declarat Compose Multiplatform pentru iOS stabil în mai 2025, odată cu versiunea 1.8.0. KMP nu mai e doar un strat de logică: notele de lansare descriu integrarea Compose într-o aplicație iOS existentă și includerea de componente native într-un ecran Compose, așa că o echipă poate partaja unele ecrane și le poate păstra native pe altele. Flexibilitatea e utilă. Readuce însă întrebarea din 2024 în altă formă. Aceleași note de lansare enumeră derularea care urmează fizica nativă din iOS și selecția nativă a textului printre detaliile pe care JetBrains a trebuit să le pună la punct, adică exact munca de recuperare pe care o cere orice interfață comună pe iOS.
Partea de iOS a rămas punctul slab al KMP. Potrivit documentației Kotlin, Kotlin/Native comunică cu Swift indirect, prin Objective-C. Funcțiile suspend ajung în Swift ca funcții cu completion handler sau ca funcții async. Chiar anunțul Google din 2024 trimitea la SKIE, unealta Touchlab care face tipurile moderne și corutinele utilizabile din Swift. Calea directă, Swift export, este descrisă tot ca Alpha. În practică, un dezvoltator iOS dintr-o echipă KMP lucrează cu un API generat, pe care nu l-a proiectat el. E un cost real și cade pe platforma ai cărei utilizatori sunt cei mai pretențioși cu finisajul.
Cel mai bun argument împotriva acestei împărțiri este costul. O interfață nativă înseamnă două coduri de interfață, două seturi de competențe și două runde de testare a interfeței. Pentru o echipă mică, cu un singur designer, care face o aplicație internă pentru angajați, e greu de justificat. Angajații folosesc aplicația pentru că le-o cere munca, nu pentru că arată ca iOS. Un singur cod în Flutter sau în React Native le dă o aplicație funcțională pe ambele platforme, făcută de o singură echipă, iar dacă interfața rămâne cu un an în urma unui redesign al platformei, nu pleacă nimeni.
E o decizie corectă, iar concluzia de aici nu o acoperă. Concluzia nu se aplică nici în alte trei situații:
Pentru un produs folosit de clienți pe ambele platforme, cu reguli importante pentru business, partajați logica și păstrați interfața nativă. Anunțul Google din mai 2024 nu a făcut KMP perfect. A adus sprijinul proprietarului platformei și un exemplu de utilizare în producție la scară mare. Pentru echipa și produsul descrise mai sus, acestea susțin recomandarea mea; nu dovedesc un risc mic pentru orice proiect. Interfața este locul unde utilizatorii judecă produsul, iar platformele o schimbă mereu.
Serviciul nostru de aplicații pentru iPhone și iPad acoperă produse pentru aceste dispozitive. Reutilizarea codului într-o viitoare aplicație Android este o decizie de arhitectură pentru fiecare proiect: depinde de locul regulilor, de competențele echipei și de funcționalitățile agreate. Pornirea doar pe iPhone nu cere un modul Kotlin comun.
fetch, rutinele pentru rutele GET și navigarea din browser nu mai urmau să fie puse în cache în mod implicit. Formularea era prudentă: „Based on your feedback, we re-evaluated our caching heuristics” („Pe baza feedbackului vostru, am reevaluat regulile de cache”).
La doi ani distanță, citirea mai directă rămâne valabilă. Cache-ul implicit pentru date a fost o alegere greșită. Aplicațiile păreau rapide în demo și afișau, fără să se vadă, date greșite în producție. Costul îl plăteau tocmai cei care îl observau cel mai greu: programatorul care a moștenit aplicația și clientul care vedea prețurile de ieri. Un framework ar trebui să servească implicit date proaspete, iar cache-ul să fie o decizie pe care cineva o numește și și-o asumă. Dacă aveți în producție o aplicație Next.js 14 cu App Router, mai ales una scrisă de altcineva, merită să verificați unde servește date vechi fără să știe nimeni.
Documentația de cache din Next.js 14 descrie deschis designul. Enumeră patru mecanisme de cache separate (în engleză): Request Memoization, Data Cache, Full Route Cache și Router Cache, cel din browser. Apoi spune regula: implicit, Next.js pune în cache cât de mult poate, ca să crească performanța și să scadă costurile, deci rutele sunt randate static, iar cererile de date sunt puse în cache, dacă nu renunțați explicit.
Concret, asta însemna:
fetch pe server fără opțiunea cache folosea force-cache (în engleză), iar rezultatul ajungea în Data Cache, care se păstrează și de la un deploy la altul. O versiune nouă nu îl golea. Funcțiile dinamice precum cookies() și configurația segmentului puteau schimba regula; lipsa opțiunii nu dovedește singură folosirea cache-ului.cookies(), headers(), parametrii din URL) și fără cereri de date care ocolesc cache-ul era randată static, la build (în engleză). O pagină care citea direct din baza de date printr-un ORM, fără fetch, nu îi dădea lui Next.js nimic de detectat, așa că era randată o dată și servită apoi la fel.GET erau puse în cache dacă nu foloseau o funcție sau o configurare dinamică, după cum amintește anunțul versiunii RC (în engleză).Fiecare alegere se poate apăra separat. Împreună produc o eroare pe care mediul de dezvoltare o ascunde. Aceeași documentație precizează că, în development, datele din fetch sunt refolosite pentru Hot Module Replacement, iar opțiunile de cache sunt ignorate la un hard refresh. Programatorul reîncarcă pagina, vede date proaspete și trece mai departe. Full Route Cache apare abia după next build. Primul care vede pagina învechită e un utilizator din producție, iar ce raportează („am modificat și nu s-a schimbat nimic”) pare o eroare a funcționalității, nu a cache-ului.
Versiunea RC a schimbat trei valori implicite. Notele de lansare (în engleză) dau titlurile a două dintre pull requesturi fără ocolișuri: „[Breaking] Disable automatic fetch caching” și „[Breaking] disable client router cache for page segments”. Next.js 15 stabil (în engleză) a păstrat schimbările pe 21 octombrie 2024 și le-a trecut între modificările incompatibile. fetch nu mai folosește implicit force-cache. Rutinele pentru rutele GET nu mai sunt puse în cache. Router Cache are un staleTime de 0 pentru segmentele de pagină, deci navigarea obișnuită nu mai refolosește implicit acele segmente de pagină. Cache-ul de pe server și paginile statice pot conține totuși date vechi.
Trei zile mai târziu, Sebastian Markbåge a spus în articolul Our Journey with Caching (în engleză, 24 octombrie 2024) ce notele de lansare doar lăsau să se înțeleagă: experiența programatorilor a avut de suferit din cauza valorilor implicite și a controalelor de cache oferite. A numit și cauzele: fetch pus implicit în cache, prea puțin control asupra accesului la baza de date fără fetch și un șir de configurări pe segment (dynamic, fetchCache, revalidate), adăugate ca soluții de avarie. Modelul experimental pe care îl descria vă cere să decideți, pentru fiecare dată, dacă e pusă în cache sau e citită la fiecare cerere. În cuvintele lui: „Nothing is cached by default. No more hidden caches.” („Nimic nu e pus implicit în cache. Gata cu cache-urile ascunse.”)
Modelul a devenit Cache Components în Next.js 16 (în engleză, 21 octombrie 2025), construit în jurul directivei "use cache" și activat dintr-o opțiune de configurare. Anunțul îl pune în contrast cu cache-ul implicit din versiunile anterioare ale App Router și spune că, în Cache Components, cache-ul e în întregime opțional. Două versiuni majore la rând au mers în aceeași direcție, deci chiar cei care întrețin framework-ul le-au dat dreptate criticilor.
Vechea regulă merită judecată corect. Pe majoritatea site-urilor, paginile sunt citite mult mai des decât se schimbă. Cache-ul implicit îi dă fiecărei echipe încărcarea rapidă a unui site static fără să-i ceară să înțeleagă cache-ul și ține jos încărcarea bazei de date și factura de hosting. Fără cache implicit, costul se mută pe fiecare cerere, iar echipele care nu se gândesc niciodată la cache îl plătesc în latență și în resurse de calcul. Markbåge recunoaște compromisul: mutarea citirii datelor pe server a însemnat sacrificarea încărcării inițiale foarte rapide din modelul Jamstack.
Argumentul are dreptate în privința costului, dar greșește în privința celui care trebuie să poarte riscul. O pagină lentă și corectă apare în monitorizare, iar cineva o repară adăugând un cache cu bună știință. O pagină rapidă și greșită apare ca reclamație, ca tichet la suport sau ca o comandă plasată la un preț vechi, iar cineva trebuie să caute cauza înapoi, prin patru niveluri de cache. Datele vechi sunt o eroare de corectitudine. Când o valoare implicită greșește, ar trebui să greșească într-un fel care se vede.
Schimbarea nu a făcut din Next.js 15 un framework fără cache, iar echipele care au făcut upgrade așteptând asta au avut surprize. Documentația fetch din Next.js 15 numește noua valoare implicită „auto no cache”: în development, Next.js citește resursa de la server la fiecare cerere, dar la next build o citește o singură dată, pentru că ruta e prerandată static (documentația fetch, v15, în engleză). O rută fără API-uri dinamice e construită tot o dată și servită ca atare. Problema pe care mediul de dezvoltare o ascunde rămâne, mai îngustă, pentru rutele statice. Anunțul RC enumera și ce rămâne în cache: layouturile comune nu sunt recitite la navigare, navigarea înapoi și înainte se face din cache, iar loading.js se păstrează cinci minute.
Pentru unele aplicații, teza contează mai puțin. Un site de prezentare, o documentație sau un blog care se reconstruiește la fiecare modificare de conținut era bine servit de vechea regulă, pentru că acolo randarea statică e chiar scopul. Argumentul privește aplicațiile ale căror date se schimbă între două deployuri: comenzi, stocuri, rezervări, pagini de cont, ecrane de administrare.
Majoritatea aplicațiilor Next.js 14 încă în funcțiune au fost scrise cu vechile valori implicite, adesea de cineva care între timp a plecat. Dacă preluați o astfel de aplicație, aceste verificări ajută la găsirea riscurilor de date vechi înaintea utilizatorilor.
next build și next start cu date apropiate de cele reale. Modificați o înregistrare și reîncărcați pagina. Cu next dev nu veți vedea problema.fetch de pe server fără opțiunea cache sau next.revalidate explicită. Sunt candidați pentru verificare, nu dovezi de cache. Referința v14 dă force-cache ca valoare implicită dacă nu s-a folosit o funcție dinamică precum cookies(); setările efective dynamic și fetchCache pot schimba comportamentul. Verificați ordinea apelurilor, configurația moștenită și contextul cererii.GET: are o funcție dinamică sau export const dynamic?revalidatePath sau revalidateTag și eventuala reîmprospătare din client. Revalidarea dintr-un Route Handler lasă Router Cache din browser învechit 30 de secunde pe paginile dinamice și cinci minute pe cele statice.Soluția e ca fiecare decizie să se vadă în cod. În Next.js 14, opțiunile arată așa:
Pentru o rută care afișează comenzi și catalogul, păstrați modul implicit dynamic = 'auto' și verificați setările fetchCache moștenite. Dați comenzilor opțiunea explicită cache: 'no-store'; astfel ruta nu intră în Full Route Cache. Pentru catalog, folosiți explicit cache: 'force-cache', cu next.revalidate: 300 și eticheta catalogue. Ghidul v14 permite citiri cu și fără cache într-o rută randată dinamic. Nu adăugați dynamic = 'force-dynamic': dezactivează și Data Cache, anulând politica pentru catalog. Aceasta este o explicație de configurare verificată în documentația versiunii, nu un exemplu executat; verificați ruta concretă în modul de producție înainte să vă bazați pe ea.
În această configurație, intenția este citirea comenzilor la fiecare cerere și revalidarea catalogului după cinci minute. Comportamentul trebuie verificat pentru ruta și versiunea instalate.
Decizia de upgrade vine după această verificare. Trecerea la 15 sau 16 schimbă valorile implicite, dar nu vă spune pe care dintre vechile citiri din cache se baza afacerea. Un upgrade fără verificare înlocuiește un set de surprize cu altul.
Lecția se aplică oricărui cache de care depinde o afacere: un CDN în fața unui API, un nivel Redis, un raport precalculat, datele offline ale unei aplicații mobile. Fiecare ar trebui să aibă un nume, un responsabil, o durată de viață declarată și un eveniment cunoscut care îl golește. Un cache pe care nu l-a ales nimeni e un cache la care nu se gândește nimeni când un client spune că cifrele sunt greșite. Next.js a avut nevoie de două versiuni majore ca să facă din asta regula implicită. O aplicație pe care o administrați poate ajunge la acest standard mai repede, iar locul acestei munci e mentenanța de rutină.
fetch, documentația v15 (în engleză), Next.jsPentru o firmă mică, primul pas rezonabil este să păstreze o cale de mutare a serviciilor. Controlul domeniului și copiile necesare recuperării trebuie să rămână accesibile din afara contului de găzduire. Aflați unde depinde și DNS de același furnizor, apoi verificați mutarea printr-un exercițiu. Separarea DNS merită făcută când justifică munca suplimentară de administrare. Scopul este să puteți continua activitatea fără cooperarea furnizorului de la care plecați.
Robin Dev a publicat pe 26 mai 2024 relatarea unei dispute cu Cloudflare. Autorul se prezenta ca inginer de sisteme la un cazinou online. El susținea că firma fusese presată să cumpere un contract Enterprise anual de 120.000 de dolari și că domeniile fuseseră eliminate pe 16 mai. Potrivit relatării, au fost afectate site-ul, e-mailul și sistemele interne de acces. Data publicării textului nu este data presupusei eliminări.
Aceasta este versiunea clientului. Relatarea nu stabilește independent motivele Cloudflare sau răspunderea contractuală, iar analiza de față nu tranșează disputa. Privită din noiembrie 2026, întâmplarea ridică o întrebare utilă pentru orice firmă: câte servicii esențiale ar putea deveni indisponibile împreună dacă un singur cont ar fi blocat? Răspunsul contează indiferent cine a avut dreptate în acel conflict.
Cereți persoanei care vă administrează aplicația să urmărească drumul unui vizitator către site. Înregistrarea domeniului vă păstrează dreptul de a folosi numele. DNS indică unde se găsesc serviciile. Găzduirea asigură rularea site-ului, iar o rețea de distribuție a conținutului, numită CDN, se poate afla în fața lui. E-mailul poate avea alt furnizor, dar depinde de înregistrările DNS ale domeniului.
Urmăriți apoi recuperarea conturilor. La ce adresă ajung mesajele pentru resetarea accesului? Unde sunt instrucțiunile pentru instalarea aplicației? Administratorul se autentifică printr-un serviciu controlat din același cont? Puteți avea mai mulți furnizori și totuși o singură cale de recuperare, care devine inutilizabilă odată cu serviciul afectat.
O evidență utilă arată cine poate modifica fiecare serviciu, unde sunt păstrate datele de recuperare și ce rămâne accesibil după suspendare. Asigurarea unei agenții că se ocupă de toate nu răspunde acestor întrebări. Firma trebuie să știe cine controlează domeniul și cine poate interveni când persoana tehnică obișnuită nu este disponibilă.
Începeți cu înregistrarea domeniului într-un cont separat de găzduire, la un furnizor de înregistrare a domeniilor care permite schimbările de servere de nume de care aveți nevoie. Protejați contul prin autentificare puternică. Datele de recuperare nu trebuie să depindă exclusiv de e-mailul domeniului afectat. Limitați accesul curent, dar păstrați o cale autorizată de recuperare.
Numele diferit al unui furnizor nu este suficient. Documentația actuală Cloudflare Registrar precizează că domeniile înregistrate acolo trebuie să folosească serviciul DNS autoritativ Cloudflare. Este o condiție verificată în documentația actuală pentru această analiză, nu o afirmație despre regulile exacte din mai 2024. Exemplul arată de ce trebuie verificat controlul pe care îl păstrați, nu doar numărul serviciilor facturate.
DNS poate rămâne la furnizorul CDN dacă firma acceptă conștient dependența și îl poate reconstrui în altă parte. Un serviciu DNS separat aduce și obligații de administrare. Pentru o firmă mică, înregistrarea independentă a domeniului, un export DNS păstrat în altă parte și o mutare verificată pot fi un început potrivit. Întârzierea care rămâne trebuie cunoscută.
Păstrați datele aplicației și materialele de recuperare în afara contului pentru a cărui indisponibilitate vă pregătiți. Includeți fișierele necesare reconstruirii, instrucțiunile de instalare și o modalitate controlată de recuperare a secretelor necesare. Verificați restaurarea. Faptul că plătiți o funcție de copiere automată nu dovedește că aplicația poate fi recuperată din copia obținută.
Cloudflare descrie exportul înregistrărilor DNS, o evidență pe care o puteți păstra separat. Fișierul rezultat nu dovedește că aplicația, politicile de acces și regulile pentru trafic pot funcționa la alt furnizor. Pentru acestea sunt necesare instrucțiuni și înlocuitori proprii.
Prin mutarea traficului se schimbă și protecția din jurul aplicației. Expunerea directă a serverului inițial nu trebuie considerată automat o soluție sigură de urgență. Certificatele oferă un exemplu concret: Cloudflare avertizează că certificatele Origin CA pot produce erori de încredere în browser dacă traficul ocolește serviciul său proxy. Avertismentul provine din documentația actuală. Planul trebuie să stabilească o cale validă către serviciul înlocuitor înainte de schimbarea DNS.
Responsabilul tehnic trebuie să țină cont și de răspunsurile DNS păstrate temporar, precum și de DNSSEC, mecanismul de autentificare a acestora. Schimbarea serverelor de nume fără coordonarea înregistrărilor de încredere poate întrerupe rezolvarea numelor, după cum explică documentația Cloudflare pentru migrare. Reducerea duratei de păstrare a unei înregistrări nu garantează trecerea imediată a tuturor vizitatorilor pe noua rută. Firma are nevoie de o estimare verificată, cu condițiile ei, nu de o promisiune universală exprimată în ore.
Un exercițiu util pornește de la presupunerea că panoul furnizorului inițial nu poate fi folosit. Cereți responsabilului tehnic să restaureze o copie recentă într-un mediu izolat, folosind numai materialele păstrate separat. Verificați o operațiune reprezentativă pentru clienți și stabiliți cum ar fi redirecționate traficul și e-mailul. O adresă de test permite verificarea unei mari părți din plan fără mutarea site-ului public.
Consemnați ce a demonstrat exercițiul și ce nu a acoperit. Restaurarea aplicației nu demonstrează că delegarea DNS publică a fost schimbată corect. O copie veche de o zi nu recuperează comenzile primite după crearea ei. Stabiliți câtă pierdere de date poate accepta firma, alături de timpul necesar reluării activității.
Numiți persoana care poate autoriza mutarea, persoana care o execută și persoana care confirmă că serviciul poate fi folosit de clienți. Includeți un mijloc de comunicare pentru situația în care e-mailul firmei nu funcționează. Aceste decizii dau instrucțiunilor tehnice șansa să fie utile într-o urgență.
O platformă integrată poate reduce munca de mentenanță și poate ajuta o echipă mică să livreze mai mult. Mai mulți furnizori aduc conturi, facturi și configurații suplimentare. Pentru un site de prezentare unde o întrerupere este tolerabilă, un export recent și instrucțiuni de reconstruire pot fi suficiente. Un serviciu care primește comenzi continuu poate justifica pregătiri mai ample.
Recomandarea este să păstrați un control proporțional cu riscul. Folosiți platforma potrivită firmei și includeți în buget dependențele pe care le creează. Introduceți exercițiul de recuperare în mentenanța software și repetați-l când arhitectura se schimbă semnificativ. Un plan credibil arată ce se poate recupera, cine poate interveni și în ce condiții.
]]>useEffect primește mult mai puțin, pentru că compilatorul lasă deoparte, fără zgomot, componentele problematice. Faptul că aceste componente ar fi și lente este o ipoteză de verificat prin măsurare, nu o garanție a compilatorului. Pentru o echipă care preia o aplicație React existentă, compilatorul e util mai întâi ca audit: arată unde codul nu respectă modelul React. Ștergerea apelurilor useMemo e ultimul pas al acestei munci, nu primul.
Pe 15 mai 2024, la React Conf, echipa React a anunțat că React Compiler devine open source și a publicat o versiune experimentală. Ideea era simplă: un instrument care rulează la build și memoizează automat componentele și hook-urile, adică reține rezultatele între randări, ca dezvoltatorii să nu mai scrie de mână useMemo, useCallback și React.memo.
Condițiile au venit odată cu anunțul, în discuțiile grupului de lucru al compilatorului. Cu două săptămâni înainte de conferință, echipa a explicat că compilatorul validează static regulile React și că, atunci când găsește o încălcare, sare peste componenta sau hook-ul respectiv și compilează restul codului (30 aprilie 2024). Cu două zile înainte, notele despre compatibilitatea cu bibliotecile au adăugat cealaltă jumătate: acolo unde nu poate stabili dacă un cod e valid, de exemplu când acesta apelează o funcție externă, compilatorul presupune că regulile sunt respectate (13 mai 2024).
Așadar, din prima zi compilatorul a luat două tipuri de decizii fără să-i spună mare lucru celui care răspunde de aplicație: sare peste ce vede că e greșit și are încredere în ce nu poate vedea. Primele reacții nu au citit lucrurile așa. Unul dintre primele comentarii din discuția de pe Hacker News din ziua lansării îl descria ca pe o baghetă magică ce avea să accelereze foarte multe site-uri și aplicații existente fără schimbări majore în cod.
Proiectul a avansat apoi repede. Versiunea beta a apărut pe 21 octombrie 2024, cu suport pentru React 17 și 18 printr-un pachet separat, iar versiunea 1.0 pe 7 octombrie 2025, când regulile de linting ale compilatorului au trecut în eslint-plugin-react-hooks.
Comportamentul implicit contează mai mult decât anunțul. Opțiunea panicThreshold are valoarea implicită 'none': componentele care nu pot fi compilate sunt lăsate deoparte, build-ul continuă, iar acele componente rulează normal, fără optimizările React Compiler; procesarea obișnuită la build continuă. Documentația recomandă această setare pentru orice build de producție.
Pentru un instrument care nu are voie să strice build-ul, e alegerea corectă. Înseamnă însă că, dacă activați compilatorul într-un cod vechi, obțineți un build reușit și o aplicație care merge, fără nicio indicație despre cât din ea a fost optimizat. Funcțiile ocolite pot avea încălcări ale regulilor sau alte motive de excludere. Citiți diagnosticul înainte să decideți unde e nevoie de o corectură.
Un caz tipic este o componentă care își modifică direct datele primite:
function OrderList({ orders }) {
for (const order of orders) {
order.label = `${order.number} (${order.customer})`;
}
return orders.map((order) => <OrderRow key={order.id} order={order} />);
}
Codul modifică obiecte care aparțin componentei-părinte. Suita de teste a compilatorului conține exact acest tipar ca exemplu de eroare, cu mesajul „Modifying component props or hook arguments is not allowed. Consider using a local variable instead.” Corectura e mică și ține întâi de corectitudine, abia apoi de performanță:
function OrderList({ orders }) {
const rows = orders.map((order) => ({
...order,
label: `${order.number} (${order.customer})`,
}));
return rows.map((row) => <OrderRow key={row.id} order={row} />);
}
După ce componenta nu-și mai modifică datele primite, compilatorul o poate memoiza. Până atunci, o lasă așa cum a fost scrisă și nu vă spune nimic, dacă nu verificați explicit.
Componentele ocolite sunt o ocazie pierdută. Problema mai scumpă e codul pe care compilatorul îl compilează pentru că nu a putut detecta încălcarea. Ghidul de depanare spune că majoritatea problemelor întâlnite apar la rulare și sunt chiar de acest fel, iar cauza frecventă e codul care se bazează pe memoizare ca să funcționeze corect. Efectele care depind de faptul că un obiect își păstrează referința, listele de dependențe care au nevoie de valori stabile și cache-urile bazate pe compararea referințelor pot porni prea des, pot intra în buclă sau pot rata actualizări atunci când memoizarea se schimbă.
De aceea, anunțul versiunii 1.0 recomandă ca în codul existent useMemo și useCallback să rămână pe loc, pentru că eliminarea lor poate schimba rezultatul compilării, sau să fie eliminate doar după teste atente. Recomand și fixarea compilatorului la o versiune exactă dacă acoperirea cu teste e slabă, pentru că o versiune viitoare poate memoiza altfel și poate schimba momentul în care pornesc acele efecte. Într-o aplicație preluată, acoperirea slabă cu teste e de obicei punctul de plecare.
Chiar recomandările echipei React merg în sens invers. Pentru adoptare, grupul de lucru propune ordinea „make it work, make it right, make it faster”: activați compilatorul, verificați că aplicația merge, măsurați și abia apoi corectați încălcările raportate de linter. Textul spune clar că nu e deloc necesar să corectați întâi încălcările ca să vedeți beneficii.
Cifrele Meta susțin această ordine. Anunțul versiunii beta spune că Meta a trecut pe compilator mai multe aplicații web mari, printre care Facebook și Threads, cu puține modificări de cod, într-un monorepo cu peste 100.000 de componente. Tot acolo se arată că doar aproximativ 8% dintre pull requesturile React ale companiei foloseau memoizare manuală și că scrierea lor dura cu 31-46% mai mult. Anunțul versiunii 1.0 raportează îmbunătățiri de până la 12% la încărcarea inițială și la navigarea între pagini în Meta Quest Store.
Cred că recomandarea e corectă pentru tipul de cod pe care îl descrie. Aplicațiile Meta fuseseră, în cuvintele echipei, optimizate de mână ani la rând de inginerii Meta și de experți React, într-o companie care a scris chiar regulile. O aplicație care a trecut prin mai multe echipe, niciuna dintre ele cu linterul pornit, e cu totul altceva. Merită și acolo să activați compilatorul, dar un build reușit vă spune foarte puțin, iar numai măsurarea poate arăta dacă părțile lente coincid cu cele ocolite. Codul valid poate fi lent, iar o încălcare a regulilor poate avea un cost mic la rulare.
Pentru o echipă care tocmai a preluat o aplicație React, aceasta este ordinea pe care o susțin:
eslint-plugin-react-hooks. Raportul arată unde aplicația nu respectă modelul React, iar fiecare încălcare e un posibil bug, cu sau fără compilator.logger distinge între CompileError, pentru funcții ocolite din cauza erorilor, și CompileSkip, pentru alte motive de excludere. Înregistrați-le pe amândouă, alături de CompileSuccess, și citiți motivul; nu orice excludere este o încălcare a regulilor. Puneți lista lângă o înregistrare din profiler a ecranelor lente."use memo" și activarea la rulare printr-un feature flag. Folosiți "use no memo" doar ca excludere temporară, cu un comentariu care spune de ce.Auditul aduce valoare chiar dacă, în final, câștigul de performanță se dovedește mic. O listă a componentelor care își modifică datele primite sau citesc ref-uri în timpul randării e o listă a locurilor în care aplicația e fragilă deja azi.
O aplicație nouă ar trebui să pornească direct cu compilatorul activat. De la versiunea 1.0, Expo SDK 54 îl activează implicit, iar Vite și Next.js oferă șabloane de proiect cu compilatorul inclus. Un cod scris cu linterul pornit din prima zi are prea puțin de auditat.
Compilatorul nu e soluția nici atunci când lentoarea nu vine din randări repetate. Documentația spune că memoizarea lui vizează în primul rând performanța la actualizare și că memoizează doar componente și hook-uri, fără să împartă rezultatele între ele. Un API lent, un bundle prea mare sau o funcție costisitoare apelată din multe componente cer altă rezolvare.
În 2024, discuția s-a purtat mai ales în jurul întrebării dacă useMemo mai poate fi șters. Astăzi, întrebarea mai utilă e ce a refuzat compilatorul să compileze și de ce. Compilatorul nu a luat responsabilitatea pentru performanță de pe umerii echipei care deține codul. Diagnosticele ajută la găsirea încălcărilor regulilor și a altor limite de compilare. Echipa trebuie în continuare să le interpreteze, să măsoare rezultatul și să răspundă de corecturi.
Toate sursele sunt în limba engleză.
Pentru o aplicație în browser cu un singur server de aplicație, recomandarea este să porniți de la o sesiune păstrată pe server. Browserul primește într-un cookie HttpOnly un identificator aleatoriu, greu de ghicit. JWT merită luat în calcul când un alt serviciu trebuie să verifice independent o informație despre identitate. Echipa trebuie să poată explica și cât timp acceptă informațiile care nu mai sunt actuale.
Privită din noiembrie 2026, discuția reluată în mai 2024 oferă încă un bun punct de plecare pentru evaluarea unei aplicații. Henryk Plötz a publicat pe 26 mai 2024 un articol împotriva folosirii JWT la autentificarea obișnuită. Observația sa utilă privește datele de sesiune pe care sistemul trebuie totuși să le păstreze. Recomandarea de aici este mai restrânsă: și un sistem mic poate avea nevoie de verificare independentă. Mărimea companiei nu decide singură arhitectura.
Cookie și JWT denumesc lucruri diferite. Cookie este un mecanism al browserului pentru păstrarea și transmiterea datelor. JWT este un format pentru informații declarate despre un subiect, de exemplu despre un utilizator. Un JWT poate fi transmis într-un cookie. La rândul său, un identificator de sesiune poate fi transmis și prin alte mijloace.
În varianta recomandată, cookie-ul conține un identificator fără informații despre utilizator, iar serverul caută înregistrarea sesiunii. Într-un sistem care verifică local un JWT semnat, serviciul verifică semnătura și aplică regulile de acceptare. RFC 7519, publicat în mai 2015, definește formatul JWT și câmpuri precum subiectul, destinatarul și expirarea. Semnătura nu ascunde automat conținutul; criptarea este o alegere separată.
Întrebarea de proiectare este ce trebuie să afle serviciul înainte de următoarea cerere. Dacă oricum citește din baza de date permisiunile actuale ale utilizatorului, verificarea independentă a unui JWT s-ar putea să elimine mai puțină muncă decât sugerează schema sistemului. Aceasta este o observație despre arhitectură, nu rezultatul unui test de performanță.
Ștergerea unui JWT din browser nu anulează o copie ajunsă în altă parte. Dacă serviciul verifică doar semnătura și expirarea, copia poate rămâne valabilă până la sfârșitul perioadei acceptate. O durată scurtă limitează intervalul. O evidență a valorilor JWT retrase sau o verificare a stării actuale a contului poate opri accesul mai devreme, dar serviciul trebuie să consulte acele informații.
Și mecanismul de reînnoire are nevoie de reguli proprii. Retragerea valorii folosite pentru reînnoire poate opri emiterea unor valori noi pentru acces, fără să anuleze imediat valoarea deja emisă la fiecare serviciu care o verifică independent. RFC 7009, publicat în august 2013, discută variantele de retragere, dificultățile folosirii unor date de acces care conțin informațiile necesare verificării și folosirea unor durate scurte de valabilitate. Existența unei funcții de retragere nu dovedește că accesul se oprește imediat peste tot.
Cu o sesiune pe server, regula se exprimă mai direct: înregistrarea este invalidată, iar cererile următoare sunt respinse la verificarea ei. Implementarea rămâne esențială. O copie temporară a sesiunii poate întârzia efectul, iar o cerere deja autorizată poate ajunge la capăt. Stabiliți dacă promisiunea privește cererea următoare, un export în desfășurare sau o conexiune deja deschisă. Fiecare caz cere o decizie proprie.
Ghidul OWASP pentru securitatea HTML5 recomandă să nu păstrați identificatorii de sesiune în localStorage, unde JavaScript îi poate citi. Un cookie HttpOnly reduce acest risc de extragere. Nu elimină efectele unui atac prin injectarea de cod în pagină: acel cod poate încă executa acțiuni folosind browserul autentificat.
Pentru sesiuni, folosiți mecanismul întreținut al cadrului de dezvoltare, cu atributele Secure și HttpOnly, o politică SameSite potrivită și protecție împotriva falsificării cererilor între site-uri. Schimbați identificatorul după autentificare și după modificările relevante ale privilegiilor. Aplicați expirarea și invalidarea pe server. Aceste măsuri sunt descrise în ghidul OWASP despre sesiuni. Documentația a fost consultată în forma actuală pentru această analiză retrospectivă; nu este prezentată ca o copie din mai 2024.
Nici această recomandare nu justifică un sistem de autentificare construit din fragmente de cod găsite separat. Locul unde păstrați sesiunile trebuie administrat, iar disponibilitatea și consecvența datelor contează. Baza de date existentă poate fi potrivită. Un serviciu suplimentar trebuie justificat prin cerințe, fiindcă aduce și muncă de operare.
Un serviciu poate avea nevoie să verifice o informație despre identitate fără să contacteze emitentul la fiecare cerere. Separarea dintre organizații, conectivitatea intermitentă sau o cerință explicită de disponibilitate pot justifica alegerea. Precizați ce independență este necesară și ce întârziere acceptați înainte ca o permisiune retrasă să nu mai fie recunoscută.
Pentru valorile semnate folosite la autentificare, folosiți o implementare întreținută și reguli clare de verificare. RFC 8725, publicat în februarie 2020, tratează algoritmii acceptați, verificarea emitentului și a destinatarului, precum și separarea tipurilor de JWT. Schimbarea cheilor cere și ea un plan: cum află serviciile cheia nouă și când încetează să o accepte pe cea veche?
Sesiunea din browser poate coexista cu schimbul de informații semnate între servicii. Un furnizor extern de identitate poate participa la autentificare, iar aplicația poate păstra propria sesiune. Niciuna dintre variante nu înlocuiește verificarea permisiunilor. Nicole Tietz-Sokolskaya a explicat pe 27 mai 2024 de ce merită separate autentificarea și permisiunile. Faptul că o identitate este validă nu stabilește dreptul de a citi o anumită factură.
La preluarea unei aplicații, verificați comportamentul după deconectare, suspendarea contului și schimbarea permisiunilor. Stabiliți dacă vechile date de acces mai pot fi folosite din alt browser. Urmăriți expirarea, păstrarea datelor în browser și locul din care se citesc permisiunile actuale. Pentru JWT, verificați și restricțiile privind emitentul, destinatarul și schimbarea cheilor.
Defectele descoperite cer intervenție, dar simpla schimbare a formatului poate lăsa problema intactă. Mutarea unui JWT într-un cookie nu rezolvă automat invalidarea. Înlocuirea unei integrări de identitate care funcționează poate aduce riscuri de migrare fără un câștig justificat.
Pentru aplicația obișnuită, alegeți o sesiune al cărei acces îl puteți retrage și explica. Când aveți nevoie de verificare independentă, documentați ce rămâne valabil după schimbarea accesului sau când emitentul nu poate fi contactat. Arhitectura trebuie să respecte promisiunea făcută administratorului care retrage accesul.
]]>Poziția mea, la doi ani și jumătate distanță: acordul a răspuns la o întrebare pe care mulți programatori nu și-o puseseră. Răspunsurile scrise de ei în public erau, practic, un activ controlat de platformă, pe care platforma îl putea licenția. Un programator ar trebui să pornească de la ideea că tot ce scrie în public va ajunge în datele de antrenare ale unui model. O firmă ar trebui să nu mai trateze forumurile publice drept bază de cunoștințe și să scrie ce fac propriile sisteme, pentru că doar aceste cunoștințe tehnice le controlează cu adevărat.
Anunțul prezenta parteneriatul ca pe un câștig pentru programatori: date verificate pentru uneltele AI, atribuire în ChatGPT și venituri pe care Stack Overflow le va reinvesti în funcții pentru comunitate. Reacția de pe Hacker News din aceeași zi a fost mai rece. Un comentator întreba unde își poate trece contul bancar ca să-și primească partea. Altul descria o profesie al cărei obicei de a împărtăși deschis avea să fie folosit chiar împotriva ei.
Unii utilizatori au mers mai departe și și-au înlocuit cele mai bune răspunsuri cu mesaje de protest. The Register a relatat pe 9 mai 2024 că modificările unui programator au fost anulate în mai puțin de o oră, iar contul lui a fost suspendat șapte zile. Moderatorii i-au explicat că postările devin parte din efortul colectiv al celor care au contribuit la acel conținut. Același articol cita termenii de utilizare: conținutul este licențiat către Stack Overflow „perpetuu și irevocabil”, la nivel mondial, fără redevențe și neexclusiv, iar autorul nu poate retrage permisiunea de a-l publica, distribui, stoca și folosi.
Trebuie separate păstrarea licenței și drepturile privind ștergerea. Condițiile publice actuale, actualizate la 13 noiembrie 2025, acordă drepturi irevocabile de utilizare și exploatare comercială a contribuțiilor chiar și după eliminarea lor. Postările publice au și licențe CC BY-SA. Asta nu înseamnă că orice cerere de ștergere, anonimizare sau exercitare a drepturilor privind datele personale este exclusă. Editările anulate descrise mai sus sunt un caz de protest relatat de presă, nu o prezentare completă a acestor drepturi. Platforma controlează accesul la arhiva structurată: în septembrie 2024, descria licențierea datelor ca venit recurent din abonamente.
Presa de atunci a tratat acordul ca pe o poveste despre licențe sau despre protest. Povestea mai importantă începuse deja: oamenii puneau tot mai puține întrebări.
În mai 2025, Gergely Orosz a arătat, pe baza datelor din Stack Exchange Data Explorer publicate de Marc Gravell, că numărul lunar de întrebări coborâse la nivelul din 2009, anul lansării site-ului. În ianuarie 2026, DevClass a raportat 3.862 de întrebări în decembrie 2025, față de peste 200.000 pe lună la începutul lui 2014. O mare parte din întrebări pare să se fi mutat către asistenții AI: în sondajul Stack Overflow pentru programatori din 2025, 84% dintre respondenți spuneau că folosesc sau plănuiesc să folosească unelte AI în munca de dezvoltare.
Afacerea nu s-a prăbușit odată cu traficul. Prosus, care a cumpărat Stack Overflow în 2021 pentru 1,8 miliarde de dolari, a raportat venituri în creștere pentru semestrul încheiat în septembrie 2025, potrivit aceluiași articol DevClass. Cifra îi cuprinde împreună pe Stack Overflow și GoodHabitz, iar creșterea vine în principal de la Stack Overflow. DevClass descrie un model de afaceri bazat la început pe recrutare, apoi pe versiunile private, plătite, ale software-ului de colaborare. La acestea s-a adăugat licențierea datelor, pe care blogul companiei o numește un model de venituri recurente. Niciuna dintre aceste surse de venit nu depinde de întrebările publice ale programatorilor.
Așadar, la întrebarea „mai este folosit Stack Overflow?” răspunsul depinde de ce înțelegeți prin Stack Overflow. Compania pare să meargă bine. Spațiul public, locul în care o problemă nouă primea un răspuns nou de la cineva care o rezolvase, și-a redus mult activitatea. Arhiva rămasă se vinde, iar fluxul de întrebări noi care o ținea la zi, și odată cu el cel de răspunsuri noi, s-a redus la câteva mii pe lună.
Pierderea pare mică, pentru că răspunsurile vechi sunt încă acolo, iar modelele antrenate pe ele răspund bine la întrebările vechi. S-a slăbit însă unul dintre mecanismele care produc răspunsuri la întrebări noi: o versiune nouă de framework, un serviciu cloud nou, un tip nou de eroare. Modelele pot combina informații, pot deduce și pot folosi instrumente. Afirmațiile despre API-uri și erori noi au însă nevoie de dovezi fiabile. Mai puține răspunsuri publice înseamnă o sursă de verificare mai săracă. Când cei care scriau răspunsurile întreabă acum un model, următoarea versiune a unei biblioteci primește mai puține răspunsuri publice, iar următorul model are mai puțin din ce să învețe.
Sondajul arată că programatorii știu asta. Mai mulți nu au încredere în acuratețea uneltelor AI (46%) decât au (33%), iar motivul cel mai des ales pentru care ar întreba totuși un om, de 75% dintre ei, este că nu au încredere în răspunsul AI. Soluția de rezervă pe care o numesc e un om care știe. Tocmai locul public în care îl găseau s-a micșorat.
În primul rând, nu s-a luat nimic ce nu fusese deja dat. Conținutul a fost sub CC BY-SA de la început, deci oricine îl putea refolosi în condițiile licenței. Un acord plătit care cere atribuire e, probabil, mai bun pentru autori decât colectarea automată fără licență, care se făcea oricum. În septembrie 2024, Stack Overflow spunea că toate contractele cu partenerii OverflowAPI includ obligația de atribuire.
În al doilea rând, declinul nu a început cu OpenAI. Orosz plasează prima scădere în jurul lui 2014, când moderarea a devenit mai strictă și multe întrebări au început să fie închise mai repede, și scrie că site-ul ar fi putut să se stingă și fără modelele de limbaj. Tot el arată că scăderea cea mai abruptă începe în noiembrie 2022, odată cu ChatGPT. Citite așa, datele spun că nu acordul a dus la prăbușirea întrebărilor: asistenții AI au accelerat declinul unei comunități care devenise deja neprimitoare pentru începători.
În al treilea rând, Stack Overflow contestă ideea că spațiul public moare. Pe 29 octombrie 2026, compania a publicat articolul The reports of Stack Overflow's death are greatly exaggerated, în care citează sondajul pentru programatori din 2026: 64% dintre respondenți spun că vin mai rar pe site pentru întrebări simple, dar programatorii spun și că pun întrebări mai avansate și că intră pe site ca să verifice răspunsurile date de AI. Tot acolo, compania prezintă Stack Overflow for Agents, un schimb de cunoștințe construit în jurul unui API, prin care agenții pot împărtăși cunoștințe și pot verifica soluții, și descrie Stack Internal drept un strat de context AI guvernat, destinat companiilor.
Obiecția e întemeiată față de ideea că nimeni nu mai folosește site-ul. Faptul măsurat rămâne însă același: raportul citat din ianuarie 2026 număra 3.862 de întrebări în decembrie 2025, față de peste 200.000 la vârf. „Întrebări mai avansate” e felul în care compania descrie întrebările rămase, nu o măsură a numărului lor. Iar cine intră pe site ca să verifice un răspuns AI citește arhiva, nu o completează. Sondajul din 2026 discută încrederea prin situațiile în care respondenții acceptă răspunsurile AI. Formularea nu permite o comparație directă cu împărțirea între încredere și neîncredere din 2025. Cifrele de mai sus descriu anul 2025, nu o tendință măsurată până în 2026.
Accept primele două argumente și o parte din al treilea. Ele schimbă cauza și imaginea celor care mai vin pe site, nu și concluzia. Fie că spațiul public a fost vândut, copiat sau pur și simplu abandonat, o firmă care se bazează pe el pentru răspunsuri despre propria muncă se bazează pe ceva ce nu controlează al cărui flux de întrebări publice noi s-a redus.
Forumurile publice n-au știut niciodată lucrurile care creează cele mai multe probleme într-o firmă: de ce exportul de facturi rulează la 2 noaptea, care client depinde de un câmp vechi din API, de ce echipa a ales o coadă de mesaje și nu alta. Răspunsurile acestea stăteau în mintea oamenilor și în conversațiile de pe chat. Când oamenii au plecat, au plecat și răspunsurile.
Dovada cea mai grăitoare vine chiar de la Stack Overflow. Produsul său intern, Stack Internal (fostul Stack Overflow for Teams), își începe prezentarea cu două probleme: echipa care a construit sistemul vechi a plecat fără nicio predare, iar deciziile importante se pierd în conversațiile de pe chat. Compania care a construit spațiul public vinde acum baze de cunoștințe private, pentru că acolo trebuie să stea cunoștințele de care depinde o afacere.
Nu aveți nevoie de un produs ca să începeți. Trei tipuri de documente aduc cea mai mare parte din valoare:
Asistenții AI fac aceste documente mai utile, nu mai puțin utile. Un model care primește un repository cu decizii bine documentate poate răspunde la întrebări despre acel sistem. Fără ele, ghicește.
Pentru un proiect open source, discuția publică e chiar scopul: issue-urile, forumurile și documentația trebuie să fie publice, cu prețul că vor fi folosite la antrenarea modelelor. Pentru o echipă mică, pe un stack obișnuit, care construiește un produs standard, documentația publică și un asistent AI rezolvă majoritatea întrebărilor de zi cu zi, iar o bază de cunoștințe internă ar fi doar o povară. Iar pentru întrebările despre un limbaj sau un framework, documentația oficială rămâne sursa principală, mai bună decât un forum sau un model.
Argumentul se aplică la tot ce ține de afacerea dumneavoastră: datele, integrările, deciziile și incidentele. Nimeni altcineva nu le va scrie, iar unui model nu îi puteți atribui automat aceste cunoștințe.
Acordul Stack Overflow nu a pus capăt schimbului de cunoștințe între programatori, dar a arătat cine controlează răspunsurile publice, iar următorii doi ani au arătat cât de repede se poate reduce fluxul celor noi. Tratați tot ce publicați ca date de antrenare. Tratați cunoștințele scrise ale firmei ca parte din software și întrețineți-le ca pe cod. Dacă azi nimeni din echipă nu răspunde de această muncă, locul ei e într-un plan de mentenanță.