Spec-First Software Development: Si po ndryshon Google mënyrën e zhvillimit të software-it me AI

Inteligjenca artificiale po ndryshon mënyrën se si ndërtohet software-i. Asistentët dhe agjentët e AI mund të gjenerojnë kod shumë shpejt, por shpejtësia nuk garanton që zgjidhja përputhet me kërkesat, arkitekturën dhe nevojat reale të biznesit. Kur udhëzimet janë të paqarta ose konteksti humbet gjatë bisedave të gjata, rezultati mund të përmbajë gabime, funksione të panevojshme ose vendime teknike që nuk janë menduar mirë.

Qasja Spec-First Software Development e vendos planifikimin përpara shkrimit të kodit. Në vend që agjenti AI të kalojë menjëherë nga një kërkesë e shkurtër te implementimi, fillimisht hartohet një specifikim teknik që përshkruan problemin, objektivat, kufizimet, arkitekturën dhe mënyrën e verifikimit. Ky dokument shërben si pikë reference për zhvilluesit dhe për agjentët që do të kryejnë punën.

Një shembull konkret është modeli Elephant-Goldfish (EGM), i prezantuar nga Google në blogun e tij Open Source më 22 tetor 2026. Google publikoi si projekt me kod të hapur një plugin që mbështet këtë mënyrë pune dhe që, sipas kompanisë, ishte zhvilluar fillimisht për inxhinierët e saj të software-it. Modeli synon të lidhë planifikimin me rishikimin e pavarur, përpara se AI të fillojë të shkruajë kod.

Çfarë është zhvillimi Spec-First?

Në zhvillimin tradicional, kërkesat mund të shpjegohen përmes dokumenteve, takimeve dhe komunikimit mes ekipeve. Në një proces Spec-First, këto kërkesa kthehen në një specifikim të qartë dhe të kontrollueshëm përpara implementimit. Dokumenti përshkruan çfarë duhet të bëjë sistemi, pse nevojitet, cilat janë kufizimet dhe si do të kuptohet nëse zgjidhja funksionon siç duhet.

Specifikimi mund të përfshijë përkufizimin e problemit, planin teknik, alternativat e shqyrtuara, varësitë, skedarët që do të ndryshohen, strukturat e të dhënave dhe kriteret e testimit. Sa më i qartë të jetë dokumenti, aq më pak hapësirë mbetet për interpretime të ndryshme nga agjentët AI dhe anëtarët e ekipit.

Si funksionon modeli Elephant-Goldfish i Google?

Modeli përdor dy role të ndryshme të AI-së. “Elephant” është një sesion afatgjatë me kontekst të pasur, i cili mban historikun e projektit, diskuton kërkesat me zhvilluesin dhe ndihmon në hartimin e projektimit. Në këtë fazë nuk shkruhet kod; fokusi është te qëllimi, vendimet arkitekturore dhe dokumentimi i tyre.

“Goldfish” përfaqëson sesione të reja, pa historikun e bisedës së mëparshme. Këto sesione marrin specifikimin dhe e shqyrtojnë në mënyrë të pavarur. Meqë nuk kanë marrë pjesë në diskutimet fillestare, mund të evidentojnë paqartësi, supozime të fshehura, varësi të harruara dhe raste që nuk janë mbuluar. Nëse dokumenti nuk kuptohet pa shpjegime shtesë, ai duhet përmirësuar përpara implementimit.

Nga ideja te specifikimi dhe më pas te kodi

Procesi i përshkruar nga Google zhvillohet në disa faza. Fillimisht, zhvilluesi dhe sesioni Elephant analizojnë idenë, diskutojnë alternativa dhe sfidojnë supozimet, duke respektuar parimin “No Code” gjatë projektimit. Më pas hartohet një dokument teknik në Markdown, ku përcaktohen problemi, zgjidhja, plani i implementimit dhe elementet konkrete që do të preken.

Në fazën e rishikimit, sesionet Goldfish kontrollojnë nëse specifikimi kuptohet saktë, kërkojnë dobësi logjike dhe verifikojnë nëse janë dhënë të gjitha hollësitë e nevojshme për implementim. Vetëm pasi dokumenti të jetë mjaftueshëm i qartë dhe të miratohet nga njeriu, agjenti mund të kalojë te gjenerimi i kodit. Kjo e zhvendos një pjesë të kontrollit nga korrigjimi i kodit të gabuar drejt parandalimit të gabimeve në fazën e projektimit.

Përfitimet dhe kufizimet për ekipet e software-it

Një specifikim i verifikuar mund të përmirësojë komunikimin mes zhvilluesve, drejtuesve të produktit dhe agjentëve AI. Ai krijon gjurmueshmëri të vendimeve, e bën më të lehtë rishikimin e ndryshimeve dhe ndihmon ekipin të dallojë kërkesat e domosdoshme nga supozimet. Rishikimi i pavarur mund të zbulojë probleme përpara se ato të kthehen në kod, duke ulur punën e përsëritur dhe kostot e korrigjimit.

Megjithatë, kjo qasje nuk garanton software pa gabime dhe nuk zëvendëson testimin, rishikimin e kodit, analizën e sigurisë apo gjykimin e inxhinierëve. Specifikimi mund të jetë i pasaktë, rishikuesit AI mund të humbasin probleme dhe kërkesat mund të ndryshojnë gjatë projektit. Për këtë arsye, vendimet përfundimtare, miratimi i arkitekturës dhe përgjegjësia për rezultatin duhet të mbeten te njerëzit.

Si mund ta adoptojnë bizneset këtë metodë?

Kompanitë mund të fillojnë me një projekt të kufizuar, ku kërkesat, integrimet dhe rezultatet e pritshme mund të përshkruhen qartë. Ekipi duhet të përcaktojë formatin e specifikimit, personat që e miratojnë, mënyrën e rishikimit dhe kriteret që duhet të plotësohen përpara se të nisë kodimi. Një projekt pilot ndihmon për të kuptuar nëse kjo qasje përmirëson cilësinë dhe ul paqartësitë.

Është gjithashtu e rëndësishme që dokumentet të ruhen pranë kodit dhe të përditësohen kur ndryshojnë kërkesat ose arkitektura. Kompanitë duhet të përcaktojnë kontrolle për privatësinë, sigurinë, aksesin në të dhëna dhe përdorimin e mjeteve të AI-së. Qëllimi nuk është të shtohet dokumentacion pa nevojë, por të krijohet informacion i mjaftueshëm për vendime të sakta dhe implementim të kontrolluar.

Përfundim: fillimisht qartësia, pastaj kodi

Spec-First Software Development tregon një ndryshim të rëndësishëm në zhvillimin e asistuar nga AI: vlera nuk qëndron vetëm te gjenerimi i shpejtë i kodit, por edhe te aftësia për të përcaktuar saktë se çfarë duhet ndërtuar. Modeli Elephant-Goldfish i Google e konkretizon këtë ide duke kombinuar projektimin me kontekst të plotë dhe rishikimin e pavarur të specifikimeve.

Për bizneset, kjo qasje mund të sjellë procese më të qarta, vendime më të dokumentuara dhe përdorim më të kontrolluar të agjentëve AI. Teknologjia mund të përshpejtojë implementimin, por cilësia varet ende nga kërkesat e qarta, testimi dhe gjykimi njerëzor.

Siç shprehet Ermal Beqiri, themelues i Soft & Solution Group:

“Në zhvillimin e software-it me AI, rezultati më i mirë nuk nis me sa shpejt shkruhet kodi, por me sa qartë përcaktohet problemi dhe verifikohet zgjidhja përpara implementimit.”