Programuotojo darbas keičiasi greičiau nei įpročiai
Vienas ryškiausių dabartinio lūžio signalų nuskambėjo iš Andrejaus Karpathy – vieno iš „OpenAI“ steigėjų ir buvusio „Tesla“ dirbtinio intelekto vadovo. 2025 metų pabaigoje jis viešai pripažino dar niekada taip neatsilikęs kaip programuotojas, nors pats prisidėjo prie technologijų, kurios dabar keičia šią profesiją.
Karpathy šį jausmą sieja su staigiu programavimo agentų kokybės pokyčiu. Anksčiau jie dažniau pateikdavo naudingus kodo fragmentus, kuriuos tekdavo taisyti, o vėliau jo darbo eiga vis labiau persikėlė į užduočių formulavimą ir rezultatų tikrinimą. Tai asmeninė patirtis, o ne universalus produktyvumo matas, tačiau ji tiksliai nusako naują profesinę įtampą: gebėjimas rašyti kodą nebėra tapatus gebėjimui efektyviai kurti programinę įrangą su agentais.
Šis poslinkis nereiškia, kad klasikinis programavimas išnyko. Keičiasi darbų pasiskirstymas. Modeliai gali užpildyti vis daugiau įgyvendinimo detalių, tačiau žmogus vis dar turi nuspręsti, ką kurti, kokių apribojimų laikytis, kaip atpažinti klaidą ir ar gautas rezultatas sprendžia tikrą problemą.
Kas yra „programinė įranga 3.0“
Karpathy siūloma trijų etapų schema nėra oficialus informatikos standartas, bet ji padeda suprasti vykstantį pokytį. „Programinė įranga 1.0“ – žmogaus parašytos aiškios instrukcijos. „Programinė įranga 2.0“ – neuroninių tinklų svoriai, kurių elgesys formuojamas duomenimis ir mokymo tikslais. „Programinė įranga 3.0“ – didysis kalbos modelis kaip bendresnė vykdymo terpė, valdoma natūralios kalbos užduotimis, kontekstu, pavyzdžiais ir įrankiais.
Esminis skirtumas tas, kad instrukcija nebeprivalo išvardyti kiekvieno veiksmo. Tradicinis diegimo scenarijus turi numatyti operacinę sistemą, aplankų struktūrą, priklausomybes ir galimas klaidas. Agentui galima apibrėžti norimą rezultatą, o jis pats apžiūri aplinką, vykdo komandas ir mėgina taisyti nesėkmes.
Tai gali sumažinti rankinio darbo kiekį, tačiau padidina neapibrėžtumą. Du agento paleidimai nebūtinai atliks identiškus veiksmus, o per plačios teisės gali išplėsti klaidos mastą.
Meniu programėlės atvejis: kai produktą pakeičia viena užklausa
Karpathy pateikė savo projekto „MenuGen“ pavyzdį. Programėlė fotografuodavo restorano meniu, atpažindavo patiekalų pavadinimus, generuodavo jų vaizdus ir pateikdavo naują sąsają. Vėliau tą pačią vartotojo užduotį pavyko atlikti tiesiogiai multimodaliam modeliui: pateikti meniu nuotrauką ir paprašyti joje įterpti galimų patiekalų vaizdus. Didelė dalis tarpinės programinės įrangos tapo nebūtina.
Šis atvejis parodo, kodėl naujas etapas nėra vien senų programėlių kūrimas greičiau. Kai modelis geba tiesiogiai transformuoti tekstą, vaizdą ar garsą, kai kurios anksčiau būtinos vartotojo sąsajos ir duomenų apdorojimo grandinės gali susitraukti iki užklausos.
Vis dėlto eksperimentinis demonstravimas dar nėra patikima paslauga. Produkciniam sprendimui gali reikėti užtikrinti kainų tikslumą, alergijų informacijos nekeitimą, privatumo apsaugą ir prognozuojamą atsako laiką. Kuo svarbesnės šios sąlygos, tuo daugiau deterministinio kodo ir patikrų gali tekti sukurti aplink modelį.
Kodėl kodas ir matematika juda greičiau
Karpathy dirbtinio intelekto gebėjimų netolygumą aiškina patikrinamumu. Matematinį atsakymą galima palyginti su teisingu rezultatu, kodą – kompiliuoti ir vykdyti su testais. Tokiose srityse mokymo sistema gauna aiškesnį signalą, ar bandymas pavyko. Atviro teksto kokybę, strategijos vertę ar estetinį sprendimą daug sunkiau paversti vienareikšmiu atlygiu.
Šią kryptį palaiko stiprinamojo mokymo su patikrinamais atlygiais tyrimai. Jie rodo, kad toks mokymas gali pagerinti matematikos ir programavimo rezultatus, nes teisingumą įmanoma tikrinti automatiškai. Poveikis priklauso nuo pradinio modelio, užduočių rinkinio ir nuo to, ar tikrintuvas iš tiesų matuoja norimą savybę.
Patikrinama dar nereiškia teisinga
Kodo testas patvirtina tik tai, ką jis tikrina. 2024 metais „OpenAI“ pristatė žmonių patikrintą „SWE-bench Verified“ užduočių rinkinį realioms programinės įrangos problemoms vertinti. 2026 metų vasarį bendrovė paskelbė jo nebelaikanti tinkamu pažangiausių modelių matu: dalis testų atmesdavo funkcionaliai teisingus pataisymus, o pats rinkinys galėjo būti patekęs į mokymo duomenis.
Nepriklausomi darbai rado ir priešingą problemą – per silpnus testus, priimančius klaidingas pataisas. Viename „SWE-bench“ vertinimo tyrime papildomos patikros aptiko šimtus sprendimų, anksčiau pažymėtų kaip sėkmingi. Aiškus vertinimo signalas pagreitina automatizavimą tik tada, kai jis nėra lengvai apeinamas ir pakankamai gerai atspindi realius reikalavimus.
Modeliai teisėjai turi bendrų aklųjų zonų
Atvirą tekstą ar kitą kūrybinį rezultatą galima pavesti vertinti keliems modeliams, tačiau toks metodas nėra objektyvus matavimo prietaisas. Kalbos modelių vertinimo tyrimai nustato pozicijos, autoriteto, stiliaus ir klaidingos informacijos nepastebėjimo šališkumus. Keli vertintojai gali sumažinti atsitiktinumą, bet gali dalytis tais pačiais mokymo duomenimis ir panašiomis klaidomis.
Todėl teiginys, kad ilgainiui beveik viską bus galima automatizuoti, lieka prognoze. Techninis gebėjimas sukurti vertinimo procedūrą dar neįrodo, kad ji patikimai matuos teisingumą, visuomeninę vertę, skonį ar etinę atsakomybę.
Nuo „vibe coding“ prie agentinės inžinerijos
Karpathy skiria du dažnai suplakamus darbo būdus. Vibe coding kelia programavimo „grindis“: žmogus, neturintis daug techninės patirties, gali aprašyti idėją ir greitai gauti veikiančią demonstraciją. Agentinė inžinerija kelia „lubas“: patyręs specialistas naudoja agentus didesniam darbų kiekiui atlikti, tačiau išlaiko ankstesnius saugumo, patikimumo ir priežiūros reikalavimus.
Skirtumą lemia ne tai, kiek kodo parašė žmogus, o atsakomybės disciplina. Prototipui gali pakakti, kad pagrindinis scenarijus veiktų. Produkciniame mokėjimų, sveikatos, transporto ar įmonės duomenų sprendime būtini prieigos apribojimai, testai, veiksmų žurnalai, atkūrimo procedūros ir aiški duomenų tapatybė.
Dviejų el. pašto adresų klaida
„MenuGen“ kūrimo metu agentas bandė susieti prisijungimą per „Google“ ir mokėjimą per „Stripe“ pagal el. pašto adresą. Sprendimas atrodė logiškas, tačiau vartotojas abiejose sistemose gali naudoti skirtingus adresus. Be pastovaus vidinio identifikatoriaus įsigyti kreditai galėjo būti nepriskirti tinkamai.
Ši klaida paaiškina, kodėl žmogaus vaidmuo persikelia į specifikaciją ir sistemos modelį. Agentas gali nepriekaištingai parašyti funkciją pagal neteisingą prielaidą. Testai taip pat gali praeiti, jei juose naudojamas tas pats el. pašto adresas.
Problema išryškėja tik suformulavus invariantą: mokėjimas turi būti siejamas su nekintamu vidiniu vartotojo ID, o ne su išoriniu atributu, kuris gali pasikeisti. Agentinė inžinerija todėl prasideda ne nuo ilgesnės užklausos, o nuo aiškesnių taisyklių.
Ar DI programuotojus iš tikrųjų pagreitina
Karpathy mano, kad geriausiai agentus valdantys programuotojai gali smarkiai viršyti anksčiau vartotą „dešimteriopai produktyvaus inžinieriaus“ sampratą. Tai pagrįsta jo stebėjimu ir asmeniniu darbo tempu, bet kol kas nėra universalus dydis.
2025 metais tyrimų organizacija METR atliko atsitiktinių imčių eksperimentą su patyrusiais atvirojo kodo kūrėjais. Spręsdami 246 užduotis savo gerai pažįstamose saugyklose, naudodami tuometinius DI įrankius jie vidutiniškai dirbo 19 proc. lėčiau, nors prieš darbą tikėjosi pagreitėjimo. Rezultatas galiojo konkretiems 2025 metų pradžios įrankiams ir brandžioms kodo bazėms, todėl jo negalima automatiškai taikyti naujesniems agentams ar prototipams.
2026 metų vasarį METR paskelbė vėlesnių įrankių tyrimo atnaujinimą. Tiems patiems grįžusiems kūrėjams apskaičiuotas maždaug 18 proc. pagreitėjimas, tačiau neapibrėžtumo intervalas apėmė ir nulį. Naujai įtrauktų kūrėjų rezultatas buvo dar arčiau nulio.
Tai rodo galimą lūžį, bet neleidžia teigti, kad kiekvienas programuotojas ar komanda jau dirba sparčiau. Realią naudą lemia užduočių pobūdis, modelio kokybė, ankstesnė patirtis ir laikas, kurį tenka skirti rezultatų peržiūrai.
Kur dingsta sutaupytas laikas
Agentas gali greitai parašyti daug kodo, bet produkto pristatymo laikas priklauso ir nuo reikalavimų išgryninimo, testavimo, integracijos, saugumo patikros bei peržiūros. Papildoma METR analizė parodė, kad agentų sprendimai gali būti funkcionaliai teisingi, tačiau netinkami priimti be pataisymų dėl testų aprėpties ar bendros kodo kokybės.
Todėl sugeneruotų eilučių skaičius yra silpnas produktyvumo rodiklis. Komandoms svarbiau matuoti laiką iki patikimai veikiančio pakeitimo, gedimus po diegimo, peržiūros sąnaudas ir tai, kiek agento darbo išlieka galutiniame produkte.
Netolygi inteligencija ir pasitikėjimo ribos
Karpathy dabartinius modelius vadina netolygiais: jie gali pertvarkyti didelę kodo bazę ir kartu suklysti atsakydami į elementarų kasdienį klausimą. Kaip iliustraciją jis pateikia užduotį apie už 50 metrų esančią automobilių plovyklą. Modelis gali patarti eiti pėsčiomis, nepaisydamas to, kad nuplauti reikia automobilį.
Šis pavyzdys nėra sisteminis testas, tačiau gerai parodo klaidos tipą – lokaliai pagrįstas atsakymas gali praleisti visos situacijos tikslą. Puikus rezultatas vienoje srityje nesuteikia bendros garantijos kitai, nes modelio gebėjimai priklauso nuo mokymo duomenų, užduočių ir stiprinamojo mokymo aplinkų.
Karpathy palyginimas su „vaiduokliais“, o ne gyvūnais, pabrėžia dar vieną ribą. Agentas neturi biologinių poreikių, savaiminio smalsumo ar žmogiško supratimo vien todėl, kad jo kalba įtikinama. Ši metafora nėra mokslinis sąmonės apibrėžimas, tačiau praktiškai ragina nelaikyti modelio užtikrintumo patikimumo įrodymu.
Kada reikia didesnės kontrolės
- Reikalavimai dviprasmiški. Agentas gali tiksliai įgyvendinti ne tą interpretaciją, kurios tikėjosi komanda.
- Nėra nepriklausomo tikrintuvo. Jei rezultatą vertina tas pats ar panašus modelis, klaida ir jos patvirtinimas gali turėti bendrą priežastį.
- Veiksmai sunkiai atšaukiami. Duomenų ištrynimas, mokėjimai, infrastruktūros pakeitimai ir prieigos suteikimas turi būti ribojami.
- Tvarkomi jautrūs duomenys. Platesnis kontekstas padeda atlikti užduotį, bet didina privatumo ir nutekėjimo riziką.
- Saugumas yra produkto savybė. Kalbos modelių naudojimo kibernetiniam saugumui apžvalga rodo, kad jie gali ir aptikti pažeidžiamumus, ir jų įterpti.
Kokie žmogaus gebėjimai tampa svarbesni
Agentai mažina poreikį atsiminti kiekvienos bibliotekos parametrus ar nuolat rašyti tipinį pagalbinį kodą. Kartu jie didina aukštesnio lygio gebėjimų vertę.
- Problemos formulavimas. Reikia atskirti vartotojo poreikį nuo pirmo pasiūlyto techninio sprendimo.
- Architektūra. Žmogus sprendžia, kur tinka tikimybinis modelis, o kur būtina deterministinė taisyklė ar duomenų bazės apribojimas.
- Specifikacija. Geras aprašas apima norimą rezultatą, invariantus, ribinius atvejus, prieigos teises ir nesėkmės scenarijus.
- Vertinimas. Svarbu sukurti testus, kurie tikrina ne vien patogius pavyzdžius, ir pastebėti, kada pats matas yra klaidingas.
- Produkto sprendimas. Modelis gali pasiūlyti daug variantų, tačiau komanda turi pasirinkti aiškiausią ir vertingiausią vartotojui.
- Dalykinis supratimas. Nežinant srities logikos sunku atpažinti įtikinamai suformuluotą, bet pavojingą prielaidą.
Karpathy šią ribą apibendrina mintimi, kad mąstymo veiksmus galima perduoti įrankiui, tačiau supratimo negalima tiesiog perkelti už žmogaus ribų. Agentas gali parengti planą ar kodą, bet kažkas vis tiek turi suvokti, kodėl sistema kuriama, kaip jos dalys susijusios ir kokios pasekmės priimtinos.
Agentams pritaikyta infrastruktūra
Dauguma dabartinių dokumentacijų, debesijos valdymo skydelių ir diegimo procesų vis dar sukurti žmogui. Karpathy mano, kad infrastruktūra vis dažniau turės pateikti agentui aiškiai skaitomas instrukcijas ir programines sąsajas, kad sistema galėtų pati konfigūruoti paslaugas, tikrinti būseną ir taisyti dalį klaidų.
Agentams pritaikyta sistema neturėtų reikšti neribotos autonomijos. „Anthropic“ rekomendacijos agentinėms sistemoms siūlo pradėti nuo paprasčiausio sprendimo ir didinti autonomiją tik tada, kai ji suteikia išmatuojamą naudą.
Fiksuotai, kritinei operacijai tradicinis kodas gali būti geresnis už laisvą agento sprendimą: jis pigesnis, greitesnis, pakartojamas ir lengviau audituojamas. Agentą prasmingiau įtraukti ten, kur aplinka įvairi, reikia interpretuoti nestruktūruotus duomenis arba rinktis iš kelių veiksmų.
Kaip komandai pereiti prie agentinės inžinerijos
- Pradėti nuo ribotos, patikrinamos užduoties. Tinka testų rašymas, aiškiai apibrėžtas refaktoringas, dokumentacijos atnaujinimas ar izoliuotas gedimo taisymas.
- Prieš generavimą užrašyti invariantus. Pavyzdžiui, mokėjimas visada siejamas su vidiniu vartotojo ID, o agentas negali keisti produkcinės bazės be patvirtinimo.
- Atskirti kūrėją nuo tikrintojo. Generavimą verta tikrinti nepriklausomais testais, statine analize, saugumo priemonėmis ir žmogaus peržiūra.
- Suteikti mažiausias būtinas teises. Agentas neturėtų turėti nuolatinės prieigos prie visų paslapčių, infrastruktūros ar klientų duomenų.
- Registruoti veiksmus ir turėti grįžimo kelią. Komanda turi žinoti, ką agentas pakeitė ir kaip atkurti ankstesnę būseną.
- Matuoti galutinį rezultatą. Vertinti ne sugeneruoto kodo kiekį, o pristatymo laiką, gedimus, peržiūros kainą ir vartotojo vertę.
Mažiau rašyti nereiškia mažiau atsakyti
Agentinė inžinerija perkelia programuotojo darbo centrą. Vertė vis mažiau priklauso nuo ranka įvestų kodo eilučių ir vis labiau – nuo gebėjimo pasirinkti teisingą problemą, suteikti agentui tinkamą kontekstą, suprojektuoti patikras ir sustabdyti sistemą, kai jos užtikrintumas viršija realų gebėjimą.
Karpathy vizija tiksliai užfiksuoja kryptį, tačiau neįrodo, kad programavimas jau visiškai automatizuotas ar kad visi darbai taps patikrinami vienodai lengvai. Dabartiniai modeliai vienu metu yra neįprastai pajėgūs ir netolygūs. Todėl svarbiausias profesionalumo kriterijus gali būti ne tai, kiek darbo perduodama agentui, o tai, ar žmogus vis dar supranta ir gali apginti galutinį sprendimą.
