De ce creatorul tău de aplicații cu IA îți arată mai întâi date false (și de ce e mișcarea corectă)
Dacă creatorul tău de aplicații cu IA îți umple ecranele cu utilizatori inventați și comenzi de probă înainte să atingă baza de date, asta nu e o scurtătură — e modul corect de a construi. Iată de ce.
Îi descrii o aplicație creatorului tău de aplicații cu IA. Un minut mai târziu te uiți la o interfață funcțională — pagini, butoane, un tabel cu utilizatori numiți cam „Alex Rivera” și „Priya Shah”, prețuri care n-au sens, un „Plan Pro” pe care nu l-ai cerut. Nimic nu e salvat. Dacă reîmprospătezi, datele sunt tot acolo. Dacă adaugi un utilizator nou, dispare.
Pare un truc de magie care e pe cale să se prăbușească. Nu e. Asta e partea bună a construcției. Datele simulate de pe ecranul tău sunt un prim pas deliberat, și sunt motivul pentru care baza de date care urmează se va potrivi cu adevărat cu aplicația pe care o voiai.
Ce înseamnă de fapt „mai întâi date false”
Când un creator de aplicații cu IA îți preia briefingul, nu merge direct la baza de date. Unul bun scrie mai întâi ecranele, le umple cu date de tip rezervat-locul (placeholder) plauzibile și apoi — și abia atunci — proiectează baza de date ca să se potrivească.
Datele de tip placeholder nu sunt decor. Sunt un contract. Odată ce aplicația ta spune „fiecare comandă are un nume de client, trei poziții, un total și o stare”, baza de date care se construiește în continuare trebuie să aibă exact acele lucruri, în exact acele forme. Ecranele decid cum arată datele, nu invers.
Asta e pe dos față de cum ar începe de obicei un dezvoltator om. Un dezvoltator tradițional proiectează mai întâi baza de date, apoi construiește ecranele pe baza ei. Creatoarele cu IA au inversat asta, și majoritatea oamenilor nu observă — văd doar utilizatorii falși și presupun că creatorul trișează.
De ce această ordine funcționează mai bine cu IA
Am încercat să construim baza de date și ecranele în același timp. N-a mers. Iată versiunea scurtă a motivului.
Când doi agenți IA lucrează la părți diferite ale unei aplicații fără să vadă rezultatul celuilalt, fac presupuneri incompatibile. Agentul de interfață decide că utilizatorii au un câmp „name”. Agentul de bază de date decide că utilizatorii au un câmp „fullName”. Amândouă par corecte. Împreună, nu funcționează nimic. Se aduce un al treilea agent care să cârpească nepotrivirea. Și el ghicește. Acum sunt trei presupuneri libere prin preajmă, iar aplicația pe care o previzualizezi e un Frankenstein al tuturor.
Soluția e aproape jenantă: fă un lucru mai întâi, apoi pe celălalt. Interfața se construiește. Ea notează ce date îi trebuie sub forma unui singur fișier cu utilizatori falși, comenzi false, false orice-ar-fi-despre-aplicația-ta. Agentul de bază de date citește acel fișier și se potrivește câmp cu câmp. Fără presupuneri. Fără negociere. Fără nepotrivire.
De-asta poate creatorul tău de aplicații cu IA să-ți arate o aplicație care pare gata într-un minut. N-a falsificat construcția. A făcut un sfert din construcție — partea care decide tot restul — iar baza de date e munca de zece secunde care urmează, nu următoarele zece ore.
La ce să te uiți când datele false sunt pe ecran
Ăsta e momentul peste care sare majoritatea oamenilor. Văd datele de tip placeholder și încep să ceară schimbări de culoare. Dar datele de tip placeholder sunt o întrebare care ți se pune ție. Citește-o.
Câteva exemple de lucruri la care să fii atent:
- Vocabular greșit. Aplicația pe care o voiai urmărește „expedieri”. Datele placeholder le numesc „comenzi”. Spune-i creatorului. Dacă o lași să treacă acum, fiecare ecran, fiecare câmp din baza de date, fiecare raport va folosi cuvântul greșit — iar redenumirea ulterioară nu e o operațiune dintr-un singur clic în niciun instrument, indiferent ce spune marketingul.
- Câmpuri lipsă. Factura falsă are un total și o dată. Mai ai nevoie și de un număr de comandă (PO). Mai bine îl adaugi acum, când sunt cinci facturi simulate pe un ecran, decât după ce baza de date e construită și populată cu date reale ale clienților.
- Forme greșite. Datele simulate arată „1 client, 1 adresă”. Clienții tăi reali au mai multe adrese. Creatorul nu poate deduce asta din briefingul tău. Spune-i acum, cât schimbarea formei nu costă nimic.
- Entități surprinzătoare. Creatorul a inventat un concept de „echipă” pe care nu l-ai cerut, pentru că a presupus o aplicație cu mai mulți utilizatori. Poate l-ai vrut. Poate nu. Oricum ar fi, decide înainte să se construiască baza de date în jurul lui.
O regulă utilă: dacă aplicația ta are un substantiv care nu e reprezentat în datele de tip placeholder de pe ecran, creatorul încă nu știe de el. Menționează-l înainte să dai clic pe „salvează” la prima previzualizare.
De ce contează ordinea pentru ce urmează
Odată ce datele de tip placeholder sunt corecte, construcția bazei de date e mecanică. Creatorul citește datele tale false, generează o schemă care se potrivește, scrie interogările pe care ecranele deja încearcă să le apeleze și, în final, schimbă importurile placeholder cu unele reale. Aceleași ecrane care arătau utilizatori falși arată acum orice pui tu de fapt în ele.
De obicei poți vedea schimbarea petrecându-se în timp real. O pagină care se încărca instantaneu pentru că citea un fișier local are acum o stare de încărcare de o jumătate de secundă — asta e ecranul vorbind cu o bază de date reală pentru prima dată. Majoritatea oamenilor ratează asta și nu realizează că aplicația tocmai a trecut linia de la „demo” la „lucru care poate stoca date reale”.
Motivul pentru care toate astea funcționează e că tot ce vine după — designul bazei de date, interogările, stările de încărcare, stările goale — a fost decis de ce ai văzut pe ecran în faza placeholder. Dacă ai aprobat trei coloane, primești trei coloane. Dacă ai aprobat un câmp „status” cu valorile „draft” și „sent”, exact asta acceptă baza de date. Nu există un al doilea pas de traducere în care o predare designer-dezvoltator strâmbă lucrurile.
Un mic test pe care îl poți face
Data viitoare când construiești ceva, încearcă asta: când apar datele de tip placeholder, schimbă un singur lucru la ele înainte să ceri orice altceva. Redenumește un câmp. Adaugă o coloană. Înlocuiește „utilizatori” cu „membri”. Apoi urmărește ce se întâmplă când se construiește baza de date.
Vei vedea schimbarea apărând peste tot — în designul bazei de date, în interogări, în datele de inițializare pe care creatorul le pune când aplicația e gata. Un singur cuvânt în faza placeholder s-a propagat prin toată aplicația. Asta e pârghia pe care o ai în faza asta, și e motivul pentru care „mai întâi date false” nu e un truc de tăiat colțuri. E locul unde aplicația se decide cu adevărat.
Dacă vrei să aprofundezi, articolul nostru anterior despre ce e de fapt înăuntrul unei aplicații create cu IA trece prin celelalte piese în mișcare pe care nu le poți vedea la prima privire. Tiparul e același: cea mai mare parte a pârghiei e în părțile care par că nu contează.