Ce am învățat când am început să construim cu AI

De Carmen Nicodin

De unde am pornit

În primul articol al seriei am explicat de ce mi-am schimbat perspectiva asupra AI în Dynamics și de ce cred că modul în care construim software enterprise se schimbă. De data aceasta vreau să povestesc ce s-a întâmplat când am început efectiv să construim cu ajutorul lui.

La Falcon, echipa de inginerie AI, dar și echipele .NET și Web folosesc deja AI în activitatea zilnică. Pentru noi, cei din Dynamics, provocarea era diferită: încă experimentam și încercam să înțelegem cum ar arăta o metodă eficientă de lucru în realitatea specifică Dynamics 365 Finance & Operations.

Trebuia să verificăm abordarea în condițiile reale ale ingineriei ERP și să înțelegem ce ar funcționa pentru noi. Articolele, demonstrațiile și experiențele altor echipe puteau oferi un punct de plecare, dar voiam să răspundem la această întrebare prin muncă practică.

Voiam să construim ceva.

Așa a început o călătorie mult mai interesantă decât mă așteptam.

Când calea standard nu era disponibilă

Ideea inițială era să explorăm Microsoft Copilot Studio și Model Context Protocol pentru Finance & Operations, care păreau punctul evident de pornire. Când am analizat ce ne trebuia, am întâlnit însă o problemă practică: funcționalitățile dorite necesitau versiuni online F&O mai noi decât cele disponibile în mediile noastre.

Am discutat chiar și cu un client despre un experiment comun. Nici ei nu aveau versiunea necesară, așa că discuția s-a îndreptat spre explorarea posibilităților cu Microsoft.

Aveam de ales: să așteptăm disponibilitatea traseului standard sau să găsim alt mod de a învăța.

Am ales să experimentăm.

Colegii din AI ne-au oferit un avans important, împărtășind instrumentele, modul de abordare a problemelor și lecțiile deja învățate. Pentru Dynamics, întrebarea era cum se traduc aceste idei într-un ERP cu propria logică de business, metadate, framework și constrângeri.

Participarea mea personală a fost o alegere deliberată. Nu mai scrisesem direct cod din perioada AX 2012, munca mea fiind orientată spre clienți, proiecte și consultanță. Revenirea la cod îmi permitea să evaluez din experiență directă ce poate face AI pentru inginerii Dynamics. Dacă urma să le cerem echipelor să își schimbe modul de lucru, voiam să fi trecut personal prin acel proces.

Am început cu un experiment mic

Am ales în mod deliberat un experiment limitat: un modul pentru beneficii medicale finanțate de angajator, pornind din propriul context de business. Era suficient de real pentru a ne pune în fața complexității F&O, dar suficient de restrâns pentru a înțelege ce se întâmplă în fiecare etapă.

Scenariul era simplu de explicat, însă implica noțiuni ERP reale. Angajatorul oferă un buget medical lunar pentru fiecare plan, angajații depun cereri în limita acestuia, eligibilitatea vine din înscrierea standard în beneficii, iar tranzacțiile aprobate afectează registrul bugetar.

Voiam să vedem dacă putem folosi AI pentru proiectarea, dezvoltarea și testarea unei soluții F&O funcționale. Modulul medical ne oferea un mod concret de a explora această întrebare. Am instalat F&O într-o mașină virtuală, am folosit compania demonstrativă USMF și am început.

Prima lecție: un build reușit dovedește foarte puțin

Una dintre primele lecții a revenit în mod repetat:

Un build reușit nu înseamnă că funcționalitatea merge.

Într-un caz, unor tabele personalizate care conțineau logică de business le lipsea un bloc obligatoriu de declarații. Rezultatul era un build reușit, dar cu metode goale: codul exista, compilatorul era mulțumit, însă logica nu făcea nimic. Puteam trece cu privirea peste defect ore întregi, până când un test comportamental a executat traseul real de salvare și l-a expus.

În alt caz, proprietăți aplicate unui grup de butoane făceau controalele să dispară după compilare, deși buildul reușea. În altă parte, o operațiune părea să eșueze pentru fiecare înregistrare, până când am descoperit că citeam date din compania greșită. Erau probleme obișnuite F&O, dar împreună au arătat de ce simpla compilare este insuficientă și de ce, în ERP, mediul contează la fel de mult ca implementarea când investighezi un defect.

Uneori, AI însuși greșea cu încredere, făcând aceste verificări și mai importante. O explicație plauzibilă ne putea trimite în direcția greșită dacă nu o confruntam cu comportamentul efectiv al sistemului.

Contextul contează

Calitatea rezultatului depindea mult de cât de bine ancoram AI în sistemul real. Am învățat să folosim aplicația standard F&O drept referință: implementările existente arătau tiparele de urmat, datele reale de înscriere în beneficii stabileau eligibilitatea, iar comportamentul sistemului ne ajuta să înțelegem procesul. Era o bază mai solidă pentru decizii decât o implementare care doar suna plauzibil.

Această ancorare a devenit deosebit de importantă când am depășit granițele propriului modul. Construirea unui modul nou ne dădea libertate de proiectare; extinderea unui ERP existent cerea înțelegerea comportamentului și a constrângerilor deja prezente.

De la un modul nou la comportamentul ERP existent

Am explorat apoi cum ne poate ajuta AI să extindem în siguranță comportamentul standard, într-un mod compatibil cu actualizările. Un exemplu privea cererile care depășeau bugetul medical lunar și modul în care diferența ar putea fi tratată prin salarizare. Înainte de a fixa o soluție, am investigat ce oferea deja sistemul.

Investigația a identificat un flux standard F&O care putea susține scenariul și ne-a arătat de ce prima idee nu era cea mai potrivită. Era un pas valoros dincolo de generarea codului: AI ne ajuta să investigăm aplicația existentă și să ne punem la încercare proiectarea înainte de implementare.

Pasul următor era să vedem dacă această înțelegere se transforma într-o extensie care funcționa în sistemul pornit.

Pentru etapa în care aprobarea trebuie să rezerve bugetul, am reconstruit procesul folosind framework-ul standard de workflow F&O și un exemplu real din produs drept referință. Am obținut aprobări configurabile, elemente de lucru și o urmă de audit, fără să inventăm propriile butoane și propriul flux de stări.

Am executat apoi procesul de la depunere la aprobare: cererea era trimisă, se crea un element de lucru pentru aprobare, cineva o aproba și bugetul era rezervat. Pentru confirmare am verificat mișcarea efectivă în registru, nu doar ce afișa ecranul.

A apărut și o limită a mediului de test. Traseul aprobărilor implica editorul de workflow ClickOnce și runtime-ul F&O, pe care testele noastre fără interfață nu le puteau controla. Am automatizat calculul bugetar declanșat de aprobare și am verificat manual rutarea, alegând pentru fiecare parte tipul de dovezi pe care îl puteam obține.

Testarea a devenit parte din experiment

Pe măsură ce AI genera și modifica mai repede cod, aveam nevoie de o metodă fiabilă pentru a stabili dacă rezultatul era corect. Testarea a devenit parte integrantă a experimentului: verificam presupunerile în timp ce soluția evolua, nu doar la final.

Pentru componenta destinată angajaților am creat o suită Python separată cu 21 de teste. Optsprezece rulează offline, împotriva unui gateway controlat care simulează răspunsurile F&O, pentru a verifica logica conversației și regulile de siguranță pe care trebuie să le respecte agentul. Celelalte trei sunt teste live activate explicit, care validează integrarea cu un mediu F&O real, în funcțiune.

Deși dezvoltăm testele cu ajutorul AI, scopul lor este să stabilească ce face efectiv sistemul. Compilarea reușită reprezintă o dovadă; comportamentul verificat în sistemul pornit ne spune dacă soluția funcționează.

Am început să gândim în roluri

Pe măsură ce experimentele creșteau, ne-am gândit și la felul în care puteam reproduce metoda în echipă. Dacă doar ofeream instrumente dezvoltatorilor și îi lăsam să își inventeze fiecare abordarea, obțineam o colecție de obiceiuri individuale. Aveam nevoie de o metodologie de inginerie și am început să organizăm munca în roluri distincte.

Un agent poate ajuta la analiză și proiectare, altul la implementare și altul la testarea comportamentului. Inginerul rămâne responsabil pentru soluție și pentru deciziile privind ce trebuie să se întâmple, iar agenții contribuie la părți clar definite.

Instrumentele care îndeplinesc aceste roluri vor continua să se schimbe. Ceea ce face abordarea repetabilă este proiectarea deliberată a rolurilor, a verificărilor dintre ele și a responsabilităților care rămân la inginer.

Apoi am pus o altă întrebare

Experimentul principal urmărea construirea soluției, dar odată ce modulul funcționa am început să ne gândim la ce poate oferi AI și oamenilor care folosesc ERP-ul.

Dacă AI ne poate ajuta să construim ERP-ul, poate ajuta și pe cineva să interacționeze cu el?

Întrebarea ne-a condus la un agent pentru angajați, în scenariul beneficiilor medicale. Angajații pot descrie în limbaj natural de ce au nevoie, iar agentul folosește informațiile din ERP pentru a determina planul, eligibilitatea și bugetul disponibil. Experiența este conversațională, cu o limită clară privind cine ia decizia de business.

Agentul nu decide dacă un serviciu este acoperit. F&O decide.

Agentul interpretează cererea și comunică rezultatul, în timp ce regulile de business rămân în sistemul care are autoritatea asupra lor. Extensia a arătat cum o interfață conversațională poate simplifica interacțiunea cu ERP-ul, păstrând deciziile în aplicația care le deține.

Am experimentat și cu rularea locală a componentei de limbaj, explorând aceeași separare între experiența conversațională și logica de business. Modelul sau tehnologia particulară erau secundare față de înțelegerea modului în care cele două componente trebuie să lucreze împreună.

Ce nu ne așteptam să descoperim

Unele dintre cele mai utile momente au fost cele în care sistemul ne-a contrazis presupunerile. Buildurile reușite ascundeau comportamente defecte, problemele de mediu păreau defecte de cod, iar testele eșuau fiindcă înțelesesem greșit aplicația standard. Și agenții făceau presupuneri incorecte, oferind uneori explicații convingătoare până când le verificam în sistemul pornit.

Aceste experiențe mi-au întărit convingerea că AI are nevoie de disciplină inginerească. Cazurile dificile erau cele în care aveam puține motive să punem răspunsul la îndoială până când căutam dovezi.

Cele mai periculoase răspunsuri nu erau cele evident greșite. Erau cele care păreau corecte.

Prompturile mai bune ajută, dar avem nevoie și de un proces de inginerie care să găsească greșelile înainte să ne bazăm pe rezultat.

Există muncă pe care clienții nu o văd niciodată

Una dintre cele mai importante lecții pentru mine este câtă pregătire necesită dezvoltarea asistată de AI înainte ca un inginer să ceară cod. Trebuie să înțelegem mediul, să oferim contextul potrivit și să definim comportamentul așteptat. Avem nevoie și de teste, responsabilități clare și un proces care diferențiază un răspuns convingător de unul corect.

Clienții pot să nu vadă niciodată această muncă, dar ea face posibile rezultatele vizibile. De aceea cred că următorul pas trebuie să includă o abordare comună de inginerie, pe lângă accesul la instrumentele AI, astfel încât disciplina unui experiment reușit să devină parte din livrarea zilnică.

Ce păstrăm pentru etapa următoare

După prima etapă de experimentare vedem AI contribuind în întregul proces: investigarea comportamentului ERP existent, evaluarea proiectării, implementarea soluțiilor și construirea testelor care le verifică. Fiecare contribuție depinde în continuare de judecata inginerească, mai ales când stabilim dacă dovezile sunt suficiente pentru a avea încredere în rezultat.

Pentru a duce lecțiile în echipă, avem nevoie de principii comune care să rămână utile pe măsură ce instrumentele se schimbă. A apărut astfel următoarea întrebare: cum construim un mod comun de lucru cu AI pentru echipa Dynamics, oferind dezvoltatorilor o bază consecventă pentru rolurile, verificările și responsabilitățile pe care începusem să le definim?

Privind înainte

Metodele, instrumentele și înțelegerea noastră asupra capacităților agenților evoluează deja, așa cum ne așteptam. Experimentul ne-a oferit lecții practice pe care să construim în continuare.

În următorul articol voi prezenta ce s-a întâmplat când am început să transformăm aceste lecții în ceva mai structurat: un cadru intern de inginerie, conceput pentru a lucra cu AI într-un mod mai consecvent și repetabil.

Pentru moment, lecția pe care aș păstra-o este că folosirea bună a AI cere mai mult decât prompturi ingenioase. Cere disciplina de a ancora agentul în sistemul real și de a demonstra comportamentul rezultat.

AI este rapid. Disciplina este ceea ce face acea viteză utilă.

În continuarea seriei: cum au evoluat experimentele noastre într-un cadru de inginerie și de ce o metodologie comună contează dacă AI devine parte din felul în care construim soluții Dynamics.