800 mijë rreshta kodi të rishkruar me AI: A po ndryshon migrimi i software-it?

Data: 25 Shtator 2026

Intelligent Migration

Migrimi i një sistemi të madh software nga një teknologji në një tjetër ka qenë gjithmonë një proces i kushtueshëm, i ngadaltë dhe me rrezik të lartë. Nuk bëhet fjalë vetëm për përkthimin e kodit nga një gjuhë programimi në një tjetër. Duhet të ruhen sjellja e sistemit, integrimet, performanca, siguria dhe përputhshmëria me produktet që varen prej tij.

Përdorimi i Inteligjencës Artificiale po e ndryshon shkallën në të cilën mund të realizohen projekte të tilla.

GitHub publikoi më 16 shtator 2026, me përditësim më 23 shtator, mënyrën se si Copilot u përdor për të rishkruar runtime-in e vet nga TypeScript në Rust. Rezultati përfshinte më shumë se 800 mijë rreshta Rust të përdorur në prodhim, të integruar përmes 128 pull requests. Sipas GitHub, pjesa më e madhe e kodit u shkrua nga agjentët AI, ndërsa migrimi u realizua gradualisht dhe jo përmes një zëvendësimi të vetëm të sistemit.

Ky rast tregon se migrimi i software-it me AI nuk është më vetëm një eksperiment me fragmente të vogla kodi. Agjentët e programimit mund të marrin pjesë në transformimin e sistemeve të mëdha, por rezultati vazhdon të varet nga arkitektura, testimi dhe kontrolli njerëzor.

Migrimi nuk është thjesht përkthim i kodit

Kur një sistem kalon nga TypeScript në Rust, procesi nuk mund të reduktohet në zëvendësimin e sintaksës.

Dy gjuhët kanë modele të ndryshme ekzekutimi, menaxhimi të memories, trajtimi të gjendjes dhe organizimi të varësive. Një funksion i përkthyer mund të prodhojë të njëjtin rezultat në një test të thjeshtë, por të sillet ndryshe kur ndërvepron me komponentë të tjerë.

Pikërisht për këtë arsye, migrimet e mëdha kërkojnë më shumë sesa gjenerim kodi. Duhet të kuptohet qëllimi i çdo komponenti, kontrata e tij me pjesën tjetër të sistemit dhe sjellja që duhet të ruhet pas ndryshimit.

AI Coding Agents mund ta përshpejtojnë prodhimin e kodit të ri, por nuk e eliminojnë nevojën për ta kuptuar sistemin ekzistues.

Pse GitHub e zhvendosi runtime-in në Rust

Runtime-i i GitHub Copilot ishte ndërtuar fillimisht me TypeScript, Node.js dhe motorin V8. Kjo arkitekturë kishte ndihmuar në zhvillimin e shpejtë të produktit, por krijonte kufizime kur runtime-i duhej të përdorej brenda produkteve dhe mjediseve të ndryshme.

Sipas GitHub, përdorimi i tij përmes SDK-së kërkonte nisjen e një procesi tjetër që mbante Node.js dhe V8. Kjo sillte konsum shtesë të memories, komunikim ndërmjet proceseve dhe më shumë elemente që duheshin monitoruar.

Rust u zgjodh për të krijuar një runtime me më pak varësi, përdorim më të parashikueshëm të burimeve dhe mundësi për t’u integruar drejtpërdrejt në aplikacione të shkruara në gjuhë të ndryshme.

Megjithatë, ky vendim nuk do të thotë se çdo aplikacion TypeScript duhet të kalojë në Rust. Zgjedhja e teknologjisë duhet të lidhet me kërkesat konkrete të sistemit, objektivat e migrimit dhe koston afatgjatë të mirëmbajtjes.

Agjentët AI e bëjnë të mundur një shkallë tjetër pune

Një nga elementet më të rëndësishme të këtij projekti është përmasa e tij.

Migrimi fillestar ishte vlerësuar mbi bazën e rreth 130 mijë rreshtave TypeScript, por sistemi vazhdonte të zhvillohej ndërkohë që migrimi po realizohej. Në fund, afërsisht 430 mijë rreshta TypeScript kaluan përmes procesit, ndërsa runtime-i i ri arriti në mbi 832 mijë rreshta Rust për prodhim.

Në një projekt tradicional, një transformim i tillë mund të kërkonte një ekip të madh dhe një periudhë shumë më të gjatë. GitHub shpjegon se puna u realizua kryesisht nga një developer brenda disa muajve, me ndihmën e GitHub Copilot dhe agjentëve të programimit, ndërsa pjesa tjetër e ekipit vazhdonte të zhvillonte funksione të reja.

Kjo nuk do të thotë se AI e kreu migrimin në mënyrë të pavarur. Agjentët prodhuan një pjesë të madhe të kodit, por projekti kishte nevojë për një strategji teknike, renditje të komponentëve, udhëzime të qarta dhe verifikim të vazhdueshëm.

Migrimi gradual uli rrezikun e ndryshimit

GitHub nuk ndërtoi një sistem të ri të plotë për ta zëvendësuar të vjetrin në një moment të vetëm.

Migrimi u realizua komponent pas komponenti. Çdo pull request zëvendësonte një pjesë të implementimit në TypeScript me versionin përkatës në Rust. Në këtë mënyrë, dega kryesore e projektit mbetej funksionale dhe versionet e reja mund të testoheshin gjatë gjithë procesit.

Kjo qasje e bëri çdo ndryshim më të vogël, më të kuptueshëm dhe më të lehtë për t’u kontrolluar. Kur shfaqej një problem, ai mund të lidhej me një grup të kufizuar ndryshimesh dhe të korrigjohej pa analizuar të gjithë migrimin.

Për projektet e mëdha, kjo është një nga mësimet më të rëndësishme. AI mund të prodhojë kod me shpejtësi, por ndryshimet duhet të ndahen në njësi që mund të rishikohen, testohen dhe rikthehen nëse është e nevojshme.

Testet bëhen kontrata e sjelljes së sistemit

Kur kodi rishkruhet në një gjuhë tjetër, pyetja kryesore nuk është nëse versioni i ri i ngjan versionit të vjetër. Pyetja është nëse ai ruan të njëjtën sjellje.

Për këtë arsye, testet ekzistuese luajtën rol qendror në migrim. Testet nga skaji në skaj u ekzekutuan kundër komponentëve të rinj në Rust gjatë çdo etape. Nëse një ndryshim nuk përmbushte kërkesat e përcaktuara, ai nuk integrohej në degën kryesore.

Në migrimin e software-it me AI, testet nuk shërbejnë vetëm për të gjetur gabime. Ato i japin agjentit dhe ekipit një përkufizim të verifikueshëm të sjelljes që duhet ruajtur.

Sa më i madh të jetë automatizimi i shkrimit të kodit, aq më e rëndësishme bëhet cilësia e testeve. Nëse testet janë të paplota, edhe kodi i gjeneruar mund të kalojë kontrollin pa garantuar që sistemi funksionon siç duhet në situata reale.

Regresionet nuk zhduken vetëm sepse kodi prodhohet nga AI

Gjatë migrimit u zbuluan regresione që lidhen me korrektësinë dhe performancën. Disa u identifikuan gjatë zhvillimit, disa në versionet paraprake dhe disa vetëm pasi ndryshimet kishin kaluar në përdorim më të gjerë.

Kjo tregon se gjenerimi i shpejtë i kodit nuk e eliminon rrezikun. Një agjent mund të krijojë një implementim që duket i saktë, kalon një grup testesh dhe përsëri ndryshon sjelljen në një rast që nuk ishte parashikuar.

Prandaj, verifikimi duhet të përfshijë më shumë se ekzekutimin automatik të testeve. Nevojiten code review, analiza e performancës, monitorim pas publikimit dhe mekanizma për të lidhur problemet me ndryshimet që i shkaktuan.

AI mund ta shkurtojë kohën e implementimit, por përgjegjësia për cilësinë e sistemit mbetet te ekipi që e projekton dhe e miraton ndryshimin.

Arkitektura duhet të përgatitet për migrimin

Përpara se të përkthehej pjesa më e ndërlikuar e runtime-it, projekti u nda në komponentë më të menaxhueshëm.

Elementet me logjikë të pastër dhe pa gjendje të përbashkët u trajtuan fillimisht. Komponentët më të ndërvarur, si orkestrimi i sesioneve, u lanë për fazat e mëvonshme, pasi modelet e integrimit, testimit dhe komunikimit ndërmjet TypeScript-it dhe Rust-it ishin provuar.

Kjo tregon se suksesi i migrimit nuk varet vetëm nga aftësia e AI-së për të shkruar kod. Ai varet nga mënyra si arkitektura e ndan sistemin në pjesë që mund të transformohen pa e ndërprerë të gjithë produktin.

Një sistem me kufij të qartë ndërmjet komponentëve është më i lehtë për t’u migruar, pavarësisht nëse puna realizohet nga njerëzit apo me ndihmën e agjentëve AI.

Shpejtësia e kodimit nuk është e njëjtë me shpejtësinë e migrimit

Agjentët AI mund të prodhojnë shpejt një sasi të madhe kodi. Megjithatë, migrimi përfundon vetëm kur kodi i ri është testuar, integruar, publikuar dhe provuar në përdorim real.

Nëse gjenerimi ecën më shpejt sesa kapaciteti i ekipit për të kontrolluar ndryshimet, krijohet një pengesë e re. Code review, testimi dhe analizimi i regresioneve mund të kthehen në pjesën më të ngadaltë të procesit.

Kjo do të thotë se produktiviteti nuk duhet të matet vetëm me numrin e rreshtave të prodhuar. Duhet të matet me komponentët e migruar në mënyrë të sigurt, problemet e parandaluara dhe përmirësimet reale në performancë, mirëmbajtje dhe stabilitet.

Në këtë model, AI e rrit kapacitetin e implementimit, ndërsa programuesi duhet të ruajë ekuilibrin ndërmjet shpejtësisë dhe besueshmërisë.

Roli i developer-it zhvendoset te strategjia dhe verifikimi

Në një migrim tradicional, pjesa më e madhe e kohës mund të shpenzohet duke rishkruar manualisht funksione dhe struktura të përsëritura.

Kur kjo punë mbështetet nga AI Coding Agents, developer-i mund të përqendrohet më shumë te renditja e migrimit, përcaktimi i kufijve arkitekturorë, përzgjedhja e testeve dhe analizimi i rasteve ku dy implementimet nuk sillen njësoj.

Kjo e bën rolin e tij më pak të përqendruar te prodhimi manual i çdo rreshti dhe më shumë te drejtimi i transformimit teknik.

Megjithatë, për ta ushtruar këtë rol, developer-i duhet ta kuptojë thellë sistemin. Pa njohuri mbi arkitekturën, modelet e ekzekutimit dhe kërkesat e produktit, bëhet e vështirë të vlerësohet nëse kodi i gjeneruar është realisht i përshtatshëm.

Migrimi me AI kërkon përgjegjësi të dokumentuar

Për Soft&Solution Group, përdorimi i AI-së në migrime të mëdha duhet të shoqërohet me një proces të qartë përgjegjësie.

Për çdo komponent duhet të dihet pse po migrohet, cilat udhëzime iu dhanë agjentit, cilat teste u përdorën, çfarë ndryshimesh u miratuan dhe si u monitorua sjellja pas publikimit.

Kjo histori e dokumentuar bëhet veçanërisht e rëndësishme kur kodi gjenerohet në volum të madh. Pa gjurmueshmëri, ekipi mund ta ketë të vështirë të kuptojë pse është marrë një vendim ose nga cili ndryshim ka ardhur një problem.

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

“Inteligjenca Artificiale mund ta shpejtojë ndjeshëm rishkrimin e një sistemi, por migrimi nuk matet me numrin e rreshtave të prodhuar. Ai matet me sjelljen që ruhet, problemet që parandalohen dhe sigurinë me të cilën sistemi i ri hyn në përdorim. Agjenti mund ta shkruajë kodin, por arkitektura, kontrolli dhe përgjegjësia duhet të mbeten të qarta.”

Rishkrimi i runtime-it të GitHub Copilot tregon se agjentët AI mund të përdoren edhe në transformime software me përmasa që më parë do të kërkonin kohë dhe burime shumë më të mëdha.

Por mësimi kryesor nuk është se AI mund të prodhojë 800 mijë rreshta kodi. Mësimi është se një migrim i tillë bëhet i mundur kur automatizimi kombinohet me ndarje të kujdesshme të sistemit, testim të vazhdueshëm, publikim gradual dhe mbikëqyrje njerëzore.

Migrimi i software-it me AI nuk e heq kompleksitetin. Ai ndryshon mënyrën si menaxhohet.

Loading…