Care este rolul programatorului în noua eră AI și ce ar trebui acesta să facă? Sunt câteva din întrebările panelului nostru de discuții din luna aprilie. Mi-a făcut plăcere să îi avem invitați la panel pe:

• George Todoran - Principal AI Architect @ BMW TechWorks Romania,

• Ioana Barboș - Lead AI Engineer @ RebelDot,

• Tudor Mărghidan - Senior Software @ f2pool.

Publicat în Numărul 167 Citeşte mai mult

Serverul MCP Playwright expune capabilitățile de automatizare ale Playwright printr-o interfață standardizată, permițând agenților AI să navigheze și să testeze aplicații web în timp real. Spre deosebire de automatizarea tradițională cu selectori hardcodați, agenții AI primesc descrieri semantice ale paginii și execută acțiuni. Obiectivul testării se mută spre generare de cod, interacțiune cu agenți și servere MCP și analiza și revizuirea codului generat.

În Git Flow concurent, una dintre problemele care se văd cel mai greu este contaminarea cross-release: un commit perfect valid ajunge în release-ul greșit. Buildul poate trece, testele pot fi verzi, iar code review-ul poate să nu indice nimic suspect. Problema apare abia când îți dai seama că acel cod aparținea unui release viitor și a intrat într-un release care se pregătește deja de deploy.

În multe companii, cele mai valoroase informații se află într-un PDF uitat într-un folder partajat. Proceduri, rapoarte, contracte, specificații tehnice sau documente de conformitate conțin răspunsuri importante, însă accesul la ele depinde adesea de structura arhivelor interne, de denumiri de fișiere, de versiuni păstrate în paralel și de memoria oamenilor care știu „unde trebuie căutat”. Informația există, dar nu este întotdeauna pregătită pentru a fi folosită în mod sistematic.

Discuția despre IA în software development ajunge inevitabil la aceeași întrebare: va mai fi nevoie de dezvoltatori? Experiența noastră cu Spec Kit arată că întrebarea este greșit formulată. Nu dezvoltatorul dispare, ci se schimbă locul în care acesta aduce valoare: mai puțin în scrierea manuală a codului și mai mult în definirea corectă a problemei.

Publicat în Numărul 167 Citeşte mai mult

Producerea unor release notes corecte și consecvente într-un mediu de producție modern este surprinzător de dificilă. Echipele de dezvoltatori gestionează în mod obișnuit patru sau mai multe sisteme deconectate: Jira pentru urmărirea sarcinilor, GitHub Enterprise pentru pull requesturi, baze de date Oracle pentru modificări de schemă și Confluence ca destinație canonică de publicare - fără niciun instrument care să le integreze simultan. Rezultatul este un proces manual, predispus la erori, care întârzie lansările, produce documente inconsistente și consumă timp prețios de dezvoltare cu muncă de rutină. Acest articol prezintă Release Notes Automation, un lanț intern de instrumente care elimină complet acest proces, bazat pe o arhitectură pe trei layere: un generator CLI în Java 17, microservicii Spring Boot de tip MCP(Model Context Protocol) și un Wizard de introducere a datelor găzduit pe GitHub Pages.

Publicat în Numărul 167 Citeşte mai mult

Nu este o noutate pentru nimeni că dezvoltarea software a fost schimbată permanent de instrumentele de IA pentru generarea de cod. Sunt, fără exagerare, cel mai mare salt de productivitate pe care l-am văzut în cariera mea și cred cu tărie că pot fi folosite în avantajul nostru. Dar tocmai pentru că sunt atât de eficiente, viteza pe care o oferă poate scăpa ușor de sub control.

Publicat în Numărul 167 Citeşte mai mult

Dacă echipele de produs ar înțelege cu adevărat utilizatorii, cercetarea în domeniul UX aproape că nu și-ar mai avea rostul. Nu am avea nevoie de interviuri cu utilizatorii, teste de utilizabilitate, journey mapping, analiză comportamentală, prototipare iterativă sau bucle continue de validare. Deciziile ar putea fi luate într-un mod firesc pe baza experienței, intuiției sau a unor convingeri proprii. Doar că realitatea ne arată, din nou și din nou, exact contrariul: echipe întregi construiesc funcționalități pe care nimeni nu le folosește, anumite interfețe sunt simplificate până în punctul în care anumite taskuri devin – paradoxal – mai greu de realizat, roadmapurile de produs se aglomerează cu presupuneri ambalate drept nevoi reale ale utilizatorilor. Iar distanța dintre ceea ce cred echipele că își doresc utilizatorii și ceea ce aceștia au nevoie, de fapt, este adesea mult mai mare decât am vrea să recunoaștem.

Modelele semantice au rolul de a face datele mai ușor de consumat prin Business Intelligence (BI). În Microsoft Fabric, ele devin baza pentru o utilizare mai largă a datelor, inclusiv de către sisteme automate. Articolul analizează cum modelele semantice, Semantic Link, Fabric IQ și Data Agents formează o arhitectură guvernată și reutilizabilă. Folosind un limbaj de business bine definit și componenta de artificial intelligence, se obține operaționalizarea unui raționament consecvent. Scopul articolului este de a clarifica ce este posibil astăzi, ce se află în evoluție și de ce semantica devine critică pentru BI și AI.

Publicat în Numărul 167 Citeşte mai mult