Tyrimų prioritetai ateinantiems 18 mėnesių: Kur turėtų judėti autonominis kodavimas toliau

Tyrimų prioritetai: Autonominis kodavimas ateinantiems 18 mėnesių

Dirbtinio intelekto pagrindu veikiantys kodavimo asistentai jau keičia programinės įrangos kūrimą. Iki 2025 m. pabaigos tokios priemonės kaip „GitHub Copilot“ ir dirbtinio intelekto pokalbių robotai bus naudojami kasdien daugumos kūrėjų, o net ir neprogramuotojai galės prototipuoti kodą paprastomis užklausomis. „Google“ generalinis direktorius pažymi, kad ši tendencija – dažnai vadinama „vibe kodavimu“ – daro programavimą lengviau prieinamą netechniniam personalui (www.itpro.com). Tačiau realaus pasaulio diegimai atskleidė svarbių spragų. DI sugeneruotame kode dažnai yra sunkiai pastebimų klaidų, jis neveikia sudėtinguose projektuose ir kelia atskaitomybės bei politikos klausimus. Norint pereiti nuo laboratorinių demonstracijų prie patikimų gamybos sistemų, mums reikia sutelktų tyrimų keturiose srityse: patikimumo, ilgalaikio planavimo, tikrinamumo ir socialinės-techninės valdymo. Toliau apibūdiname pagrindines atviras problemas ir siūlome tyrimų programas, etalonus bei bendradarbiavimą joms spręsti.

1. Patikimumas ir kodo kokybė

Pagrindinė problema yra bazinis patikimumas: DI asistentų parašytame kode vis dar yra žymiai daugiau klaidų nei žmogaus parašytame kode. Pavyzdžiui, 470 „GitHub“ ištraukimo užklausų (PR) analizė parodė, kad DI parašytos PR turėjo maždaug 1,7 karto daugiau problemų nei žmogaus parašytos (www.itpro.com). Vidutiniškai DI PR sukėlė apie ~10,8 problemų (loginės klaidos, pavadinimų ar formatavimo problemos, saugumo trūkumai ir t. t.), palyginti su ~6,5 žmogaus PR (www.itpro.com). Pažymėtina, kad DI sukurtame kode buvo daugiau rimtų klaidų (loginės klaidos ir saugumo pažeidžiamumas pasirodė beveik dvigubai dažniau nei žmogaus kode) (www.itpro.com). Praktikoje komandos, naudojančios DI įrankius, pranešė apie netikėtumus: kodą, kuris atrodo teisingas atskirai, tačiau neatlaiko integracijos arba turi paslėptų trūkumų. Išsamus kodo generavimo įrankių tyrimas rodo, kad esami etalonai neapima gamyboje pasitaikančių klaidų tipų – haliucinacijų API iškvietimuose, nenuoseklių pavadinimų arba sunkiai pastebimų loginių klaidų, kurios praeina vienetinius testus (doi.org). Trumpai tariant, DI gali generuoti veikiančius kodo fragmentus, tačiau šie fragmentai dažnai nėra tinkami gamybai (doi.org).

Kūrėjų patirtis atspindi šį nepasitikėjimą. Didelis „SonarSource“ tyrimas (pranešta pramonės spaudoje) parodė, kad nors 72 % inžinierių kasdien naudoja DI įrankius iki 42 % kodo rašymui, stulbinantys 96 % pripažįsta, kad visiškai nepasitiki DI rezultatais (www.itpro.com). Tačiau mažiau nei pusė komandų visada peržiūri DI sugeneruotą kodą prieš jį įrašydamos (www.itpro.com). Ši spraga – didelis naudojimas, bet mažas pasitikėjimas – veda prie to, ką ekspertai vadina „patikrinimo skola“. Be geresnio patikimumo, organizacijos rizikuoja įvesti sunkiai aptinkamas klaidas ir techninę skolą, kai tik jos pasirenka DI kodavimo nuorodas (www.itpro.com).

Tyrimų programa: Mums reikia sistemingai tirti DI kodo klaidų šablonus ir naujus metodus joms sušvelninti. Idėjos apima automatinį DI patikrinimą: statinių analizatorių arba antrinių modelių integravimą, kurie skenuoja DI rezultatus ieškodami dažnų klaidų (panašiai kaip antrasis recenzentas). Geresni didelių kalbos modelių (LLM) mokymo tikslai galėtų būti orientuoti į stabilumą – pavyzdžiui, mokymas naudojant klaidų turinčio ir švaraus kodo pavyzdžius, siekiant išmokyti modelį teikti pirmenybę saugesniems sprendimams. Tyrėjai turėtų analizuoti, kokie kodo tipai (algoritmai, įvestis/išvestis, kritiniai saugumui) suklaidina DI vidines euristikas, ir kurti specializuotas apsaugos priemones. Pavyzdžiui, ankstyvieji darbai parodė, kad DI įrankiai per daug naudoja rizikingas nuorodas (įkoduotus slaptažodžius, neefektyvius ciklus ir t. t.) (www.businesswire.com) (www.infoworld.com). Turime kodifikuoti šiuos gedimų režimus.

Edukaciniai sprendimai taip pat gali padėti: kaip pabrėžia bendruomenės gairės, DI įrankiai gali tik padėti – žmonės turi patikrinti (firefox-source-docs.mozilla.org) (chromium.googlesource.com). Siekiant tai paskatinti, ateities įrankiai galėtų automatiškai generuoti įspėjimus ar net atsisakyti atlikti užduotis be žmogaus patvirtinimo. Etalonų nustatymas turėtų keistis: pereiti nuo klausimo „ar šis kodas kompiliuojasi“ prie klausimo „kiek subtilių problemų lieka“. Pavyzdžiui, atsiranda kodo peržiūros DI modeliai, kurie konkrečiai matuoja klaidų aptikimo našumą (docs.factory.ai). Bendruomenės pastangos sukurti viešą realių DI ir žmogaus kodo pakeitimų (su anotuotais defektais) duomenų rinkinį – panašų į „CodeRabbit“ PR tyrimą – leistų tyrėjams stebėti patikimumo pažangą.

2. Ilgalaikis planavimas ir priežiūra

DI kodo generatoriai puikiai atlieka mažas, nepriklausomas užduotis, tačiau dideli projektai atskleidžia jų ribotumą. Reali programinė įranga laikui bėgant vystosi, keičiantis reikalavimams, su daugeliu failų ir valdomais architektūriniais sprendimais. Tyrimai rodo, kad „tinkamų izoliuotų funkcijų generavimas kokybiškai skiriasi nuo nuoseklių architektūrinių sprendimų palaikymo didelėje kodų bazėje“ (doi.org). Praktikoje net pažangiausi modeliai susiduria su problemomis atliekant daugiaetapes, daugiafailes užduotis. Du naujausi etalonai pabrėžia šią spragą:

• RoadmapBench (2026 m. gegužės mėn.) vertina „ilgalaikius“ atnaujinimus realiuose atvirojo kodo projektuose. Kiekviena užduotis suteikia agentui bazinę projekto versiją ir funkcijų sąrašą, kurį reikia įdiegti, pakeičiant ~3 700 eilučių daugiau nei 50 failų. Net Claude-Opus-4.7, vienas stipriausių modelių, išsprendė tik ~39 % užduočių, o kiti modeliai pasiekė vos 5 % (papers.cool). Priešingai, paprasti vienkartiniai klaidų pataisymai rodo beveik tobulą DI našumą. „RoadmapBench“ autoriai daro išvadą, kad „ilgalaikė programinės įrangos kūrimo problema išlieka iš esmės neišspręsta.“ (papers.cool)

• SlopCodeBench (2026) tiria iteracinį kūrimą. Agentams buvo duota užduotis ir sukurtas kodas, tada per 20 ciklų užduoties specifikacija keitėsi, priversdama kodą evoliucionuoti. Rezultatas: nors visos tarpinės versijos atlaikė esamus testus, DI sugeneruotos kodų bazės tapo 2,2 karto išsamesnės ir daug sunkiau prižiūrimos nei žmogaus prižiūrimas kodas (www.techradar.com). Tiesą sakant, nė vienas iš geriausių modelių neišsprendė visos sekos: sėkmės rodikliai nukrito iki ~0,5 % iki galutinio patikrinimo taško. Tai rodo, kad mažos dizaino klaidos kaupiasi naudojant DI pagalbą, trukdydamos ateities modifikacijoms (www.techradar.com).

Šie duomenys rodo, kad tyrimai turėtų būti sutelkti į planavimą ir dekompoziciją. DI sistemos neturėtų tiesiog „rašyti kodo“ pagal užklausą, bet planuoti daugiapakopes strategijas. Viena besiformuojanti idėja yra planuok-ir-vykdyk: tegul modelis pirmiausia nurodo dizainą ar žingsnių seką, tada generuoja kodą kiekvienam žingsniui (crabtalk.ai). Tiesą sakant, kodavimo agentų (Claude Code, GitHub Copilot ir kt.) analizės rodo, kad planavimo atskyrimas nuo vykdymo (ir plano atskleidimas vartotojui) žymiai pagerina našumą atliekant sudėtingas užduotis (crabtalk.ai). Tyrimai turėtų plėtoti naujas architektūras: pavyzdžiui, įdėtinius agentus, kur „vadovaujantis“ LLM didelę problemą suskaido į smulkesnes užduotis darbuotojų LLM. Taip pat reikalingi ilgalaikės atminties mechanizmai: ateities modeliai turėtų prisiminti anksčiau sesijos metu sugeneruotą kodą net už konteksto lango ribų.

Etalonai: Bendruomenė turėtų apibrėžti etalonus, atspindinčius realų kūrimo darbą. Peržengiant „RoadmapBench“ ribas, mums reikia užduočių, apimančių kelias kalbas ir integracijos iššūkius (frontend/backend, duomenų bazės ir t. t.). Imituoti komandos projektai patikrintų, kaip DI ir žmonės bendradarbiauja per leidimus. Pasinaudojant programinės įrangos inžinerijos idėjomis, etalonai galėtų matuoti ne tik teisingumą, bet ir priežiūrą (kaip lengva pridėti naują funkciją?), našumą (ar DI kodas blogėja jam tobulėjant?) ir integraciją (ar jis atitinka esamas stiliaus konvencijas?). Pavyzdžiui, etalonai galėtų prasidėti nuo esamos kodų bazės ir paprašyti agento įdiegti funkcijų užklausų seriją arba refaktoringus, su periodiniais testais. Per ateinančius 18 mėnesių, sukūrus tokius atvirus iššūkius (galbūt per akademinius-pramoninius konkursus), bus nukreipti tyrimai į daugiapakopį kodavimą.

3. Tikrinamumas ir formalios sąsajos

Kai DI asistentai imasi vis kritiškesnių užduočių, teisingumo užtikrinimas tampa esminiu. Tikrinamumas reiškia kodo susiejimą su tiksliomis specifikacijomis ar testavimo rinkiniais, kad galėtume būti tikri, jog jis daro tai, ko norime. Klasikinėje inžinerijoje prieš kodavimą rašoma formali specifikacija arba išsamūs testai. Kaip pritaikyti šį mąstymą DI valdomam kodavimui?

Viena galimybė yra „uždarojo ciklo“ generavimas. Naujausi darbai siūlo, kad DI sugeneruotas kodas, jo dokumentacijos eilutės ir bet kokios formalios anotacijos turėtų būti tikrinamos dėl nuoseklumo. Pavyzdžiui, Clover metodas automatiškai generuoja formalizuotas specifikacijas (naudojant tokias kalbas kaip Dafny) kartu su kodu, o tada naudoja įrodymo įrankius, kad atmestų nenuoseklius sprendimus (theory.stanford.edu). Ankstyvuosiuose testuose tai aptiko visas neteisingas programas vadovėlinio lygio duomenų rinkinyje. Panašiai, AutoACSL naudoja statinę analizę, kad paskatintų LLM parašyti tikslias funkcijų sutartis (pirminės/galutinės sąlygos) ir tada patikrina jas su Frama-C (papers.cool). Pateikus nepatenkintas sąlygas, jis žymiai pagerino įrodomai teisingo kodo procentą. Šie pavyzdžiai rodo, kad formalių metodų integravimas kodo generavimo etape gali paversti nekontroliuojamą DI spėjimą patvirtinta programa.

Be formalios matematikos, mums taip pat reikia geresnių sąsajų tarp neformalių specifikacijų, testų ir kodo. Šiandien įprasta aprašyti funkciją anglų kalba ir tikėtis, kad DI padarys tai, kas reikia. Tačiau taip pat turėtume paprašyti DI generuoti arba klausti testavimo atvejų, tipo anotacijų ir dizaino komentarų. Pavyzdžiui, užklausa pirmiausia galėtų paprašyti modelio apibūdinti algoritmą arba invariantus natūralia kalba arba pseudokodu, o tik tada jį koduoti. Arba galėtume naudoti „sutartimi pagrįstą“ kūrimą: parašyti vienetinius testus (arba savybių testus), kuriuos DI turi patenkinti. Šių idėjų juodraščiai parodė perspektyvumą: net kelių pavyzdiniais testais pagrįstų testų generavimas gali nukreipti modelį nuo trivialių sprendimų.

Etalonai: Nauji etalonai turėtų apimti formalaus patikrinimo problemas. Pavyzdžiui, galėtume pridėti užduotis, kuriose „teisingumas“ tikrinamas teoremų įrodymo įrankiu arba simboliniu tikrintuvu, o ne tik vienetiniais testais. Vartotojo istorijų duomenų rinkiniai su LTL/TLA+ arba Alloy specifikacijomis ir atitinkamu kodu būtų vertingi. Edukacijoje, konkursai, tokie kaip TLA+ modelio patikrinimo iššūkis, rodo, kad specifikavimas yra sunkus – vienas tyrimas parodė, kad dabartiniai LLM pasiekia tik ~8% semantinio teisingumo paprastose TLA+ specifikacijose (papers.cool). Atvirojo kodo projektai galėtų plačiau išleisti specifikacijų kalbas (savotišką kodavimo pareiškimą). Standartizuoti formatai (YAML, JSON) API specifikacijoms arba duomenų schemoms galėtų būti naudojami DI, siekiant suderinti kodą su numatytu elgesiu.

4. Socialinis-techninis valdymas ir pasitikėjimas

Galiausiai, autonominis kodavimas kelia žmonių ir politikos klausimus. Kas atsakingas už DI kodą? Kaip užtikrinti saugumą, autorių teisių laikymąsi ir atskaitomybę? Kelios organizacijos pradėjo spręsti šį klausimą, tačiau atviri klausimai išlieka.

Kūrėjų praktika: Kaip minėta, pramonės tyrimai rodo pasitikėjimo spragą. Kūrėjai žino, kad turėtų peržiūrėti DI rezultatus, bet dažnai to nedaro, jei tai lengviau, o tai veda prie nevaldomos rizikos (www.itpro.com). Reaguodami į tai, didieji projektai nustatė aiškias taisykles. Pavyzdžiui, „OpenInfra Foundation“ leidžia DI pagalbą tik tuo atveju, jei įrašai yra pažymėti „Assisted-By:“ arba „Generated-By:“ žyma (openinfra.org). „Google“ projektas „Chromium“ panašiai reikalauja, kad autoriai visiškai suprastų bet kokį DI pasiūlytą kodą, kitaip jie praras įrašymo privilegijas (chromium.googlesource.com). „Mozilla Firefox“ politika atvirai teigia: „DI gali padėti, tačiau atsakomybė visada lieka su žmogumi, atsakingu už pakeitimą“ (firefox-source-docs.mozilla.org). Net „NumPy“ projektas įspėja, kad turite gebėti paaiškinti bet kokį pateiktą kodą, nepriklausomai nuo to, ar jį parašė DI (numpy.org). Šios politikos pabrėžia, kad techninės priemonės vienos nepakanka – mums taip pat reikia aiškių darbo eigų ir kultūros.

Reguliavimas ir standartai: Platesniu mastu vyriausybės ir standartizacijos institucijos vejasi. ES baigia rengti Bendrosios paskirties DI praktikos kodeksą, kuris reikalaus skaidrumo ir saugumo priemonių iš DI modelių teikėjų (digital-strategy.ec.europa.eu). Nors tai nėra specifinė kodavimui, ji signalizuoja griežtesnę mokymo duomenų licencijų ir modelio paaiškinamumo priežiūrą – abi yra labai svarbios, jei jūsų kodo asistentas naudojo autorių teisių saugomą kodą. Panašiai, ISO ir IEEE pradėjo rengti DI standartus valdymo ir etikos srityse, nors tik keli tiesiogiai susiję su kodo generavimu. DI aktas (ES) ir artėjančios JAV gairės greičiausiai paveiks, kaip įmonės viduje vertina DI kodą.

Reikalingas bendradarbiavimas: Šių socialinių-techninių spragų užpildymui reikės bendrų pastangų. Akademikai gali tirti, kaip DI įrankiai veikia komandos našumą, pažeidžiamumo aptikimą ir licencijavimą; pramonė gali dalytis anoniminiais duomenimis apie realius su DI susijusius incidentus; standartų kūrimo institucijos (pvz., W3C, IEEE) gali įtraukti kodavimo scenarijus į etines DI gaires. Pavyzdžiui, seminarai galėtų suburti SAT-EL (programinės įrangos užtikrinimo) ekspertus su mašininio mokymosi specialistais, siekiant apibrėžti DI kodo saugumo vertinimo kriterijus. Gairės galėtų virsti standartais (pvz., „IEEE 8201: DI pagelbintas programinės įrangos procesas“), suteikdamos organizacijoms bendrą sistemą. Per ateinančius 18 mėnesių, pasiekus sutarimą dėl geriausios praktikos – per baltąsias knygas, konsorciumus ar atvirojo kodo politikos šablonus – komandos galės atsakingai pritaikyti šias priemones.

5. Tyrimų ir etalonų programa

Apibendrinant, siūlome šiuos konkrečius žingsnius tyrimų bendruomenei:

• Išplėstiniai etalonai: Sukurkite etalonų rinkinį, imituojantį realius programinės įrangos projektus. Pavyzdžiui, daugiamodulines sistemas (žiniatinklio programas, API, įterptąsias sistemas), kur DI turi įdiegti naujas funkcijas ir jas prižiūrėti. Įtraukite besikeičiančias specifikacijas (imitavimas besikeičiančių reikalavimų). Matuokite ne tik testų atlikimo rodiklius, bet ir kodo sudėtingumą, skaitomumą, saugumo metrikas ir peržiūros darbo krūvį. Bendradarbiaukite su pramone, kad gautumėte realių klaidų taisymo istorijų ir funkcijų užklausų kaip etaloninių užduočių.

• Klaidų taksonomijos tyrimas: Sistemingai kategorizuoti DI įvedamų klaidų tipus. „CodeRabbit“ ataskaita pateikė pradinį suskirstymą (loginės klaidos, pavadinimų problemos ir t. t.) (www.infoworld.com). Didesnis akademinis tyrimas galėtų surinkti PR duomenis ir klasifikuoti DI bei žmogaus klaidas. Tai padėtų nustatyti naujus modelio nuostolius (pvz., papildomas svoris saugumui) ir automatinius detektorius (įrankius, kurie pažymi tipiškai DI neteisingus šablonus).

• Planavimo ir daugiaagentų tyrimai: Tyrinėti tokias architektūras kaip planuotojo/vykdytojo agentai. Ištirti, kaip suteikti DI sistemoms tam tikrą atmintį per sesijas arba įgyvendinti hierarchinį planavimą. Bendradarbiauti su esamais agentinio DI ir robotikos darbais (daugiapakopių samprotavimo metodų pritaikymas kodui).

• Formuojamųjų metodų integravimas: Investuoti į tyrimus, tokius kaip „Clover“ ir „AutoACSL“, kurie susieja programos sintezę ir įrodymus. Skatinti formaliųjų metodų tyrėjus bendradarbiauti su NLP/ML grupėmis. Pavyzdžiui, akademiniai konkursai galėtų sujungti LLM kodo asistentus su įrodymo įrankiais bendrose užduotyse. Kurti konkursus DI sugeneruotiems įrodymams arba sutarčių išvadoms.

• Valdymo sistemos: Socialinių mokslų tyrimai apie komandos praktiką ir atsakomybę. Pavyzdžiui, vykdyti kūrėjų tyrimus: duoti komandoms DI įrankius ir stebėti, kaip jos peržiūri ir derina. Teisiniai IP tyrimai: kaip pažymi vienas tinklaraštis, „Copilot autorių teisių problema“ (nelicencijuotas kodas) yra atviras klausimas (www.systemshardening.com). Standartų kūrimo institucijos turėtų parengti aiškias gaires dėl duomenų licencijavimo ir priskyrimo DI kodui.

• Įrankiai ir sąsajos: Galiausiai, kurkite įrankių prototipus, kurie demonstruoja geriausią praktiką. Pavyzdys: DI kodavimo IDE įskiepis, kuris automatiškai vykdo statinę analizę arba testus bet kokiam DI sugeneruotam kodui ir įspėja vartotoją. Arba komandų eilutės sąsaja (CLI), kuri pažymi visas DI pagelbėtas sekcijas kodų bazėje. Skatinkite atvirojo kodo projektus priimti „DI naudota“ ženkliukus arba įrašymo pranešimų konvencijas. Šie neformalūs standartai vėliau gali būti formalizuoti.

Apibrėžus bendruomenės etalonus ir rengiant daugelio institucijų iššūkius (pvz., DI kodavimo hakatoną, skirtą pasiekti tam tikrus saugumo ar palaikomumo tikslus), galime stebėti pažangą. Pagalvokite apie tai, kaip „ImageNet“ paskatino viziją: mums reikia bendro „ImageNet kodui“, kuris atspindėtų realų vystymąsi. Ankstyvosios pastangos („RoadmapBench“, „SlopCodeBench“, „Sigmabench“ (sigmabench.com)) rodo kelią, tačiau toliau turėtume juos plėsti ir padaryti plačiai prieinamus.

6. Formalios sąsajos: specifikacijos, testai ir kodas

Pagrindinė galimybė – glaudesnė specifikacijų ir testų integracija į kodavimo ciklą. Tradiciniame kūrime, specifikacija aprašo, ką kodas turi daryti, o testai tai patikrina. DI įrankiai gali padėti juos sujungti. Pavyzdžiui, perspektyvi praktika yra specifikacijomis pagrįstas generavimas: pirmiausia parašyti (galbūt neformalią) specifikaciją, tada paprašyti DI ją koduoti. Dar geriau, specifikaciją būtų galima kurti kartu su DI. Pavyzdžiui, paprašykite asistento: „Sugeneruokite vienetinius testus šiam reikalavimui“, tada „Naudokite tuos testus kodui patvirtinti“. Tai sukuria formalią sąsają: natūralios kalbos specifikacija, testai, kuriuos ji numato, ir kodas sudaro glaudų trikampį.

Tyrimų srityje būtų galima apibrėžti standartinį specifikacijų formatą (pvz., YAML arba JSON schemą, apibūdinančią funkcionalumą) ir reikalauti, kad DI sistemos jį naudotų. Gali būti integruotos tokios pastangos kaip TLA+, Alloy arba BDD stiliaus įrankiai (Cucumber): įsivaizduokite, kad sakote DI: „prašome sugeneruoti kodą, atitinkantį šį TLA+ modelį“. Nors šiuolaikiniai LLM nėra labai geri rašant TLA+ nuo nulio (papers.cool), verta ištirti žmogaus parašytos abstrakčios specifikacijos ir DI papildyto kodo generavimo derinį. Tikslas yra palengvinti komandoms sukurti vykdomą specifikaciją (net jei neformalią), kurią DI gerbtų. Formalūs testai galėtų būti automatiškai generuojami: naujausi darbai rodo, kad GPT modeliai gali generuoti savybėmis pagrįstus testus, aprašius funkcijos elgesį.

Ambicingiau, galime sukurti formalių specifikacijų šablonus. Debesų diegimams arba saugumui kritiniam kodui apibrėžkite šabloną (pvz., „Vartotojo autentifikavimo srautas“ su laukais). DI užpildo šabloną ir generuoja kodą; patvirtinimo įrankis patikrina sutartį. Suteikdami šias sąsajas, kodavimą iš juodosios dėžės paverčiame labiau valdomu procesu. Tokios iniciatyvos kaip DI įrankiai TLA+ arba LLM į specifikacijas vertimas (vykdomas kai kuriose tyrimų grupėse) yra ankstyvieji pavyzdžiai. Praktikoje net dalinis priėmimas (prašymas DI išvesti komentarus ar tipo parašus) gali pagerinti teisingumą.

Kaip pirmąjį žingsnį kūrėjams: dabar įdiekite paprastus specifikacijos ir testų ciklus. Pavyzdžiui, jei naudojate „ChatGPT“, pradėkite sesiją rašydami „Mes norime funkcijos, kuri atlieka X, pirmiausia parašykite testus“. Tada paprašykite jo sugeneruoti įgyvendinimą. Net be sudėtingų formalių įrankių, tai įdiegia discipliną, kai DI visada generuoja kodą su pridedamu patikrinimu. Laikui bėgant šis įprotis gali būti formalizuotas į DI kodavimo standartus.

7. Bendradarbiavimas: akademija, pramonė ir standartai

Šių tikslų pasiekimui reikalingas platus bendradarbiavimas:

• Akademija gali prisidėti kurdama ir dalydamasi duomenimis bei etalonais, taip pat publikuodama griežtus vertinimus. Universitetai turėtų bendradarbiauti su įmonėmis, kad gautų realias kodų bazes testavimui. Tyrimų laboratorijos gali rengti atvirus iššūkius (su prizais) tokioms užduotims kaip ilgalaikė kodo kokybė ar patvirtinto kodo generavimas.

• Pramonė privalo teikti grįžtamojo ryšio ciklus. Įmonės, diegiančios DI kodavimo įrankius, turėtų anonimiškai dalytis klaidų statistika, dalyvių patirtimi ir funkcijų užklausomis. Technologijų įmonės taip pat gali finansuoti „DI kodavimui“ seminarus ar sesijas konferencijose (pvz., ICSE, FSE). Jos gali padaryti dalį savo politikų atviruoju kodu (kaip tai padarė „Google“ su „Chromium“ DI politika (chromium.googlesource.com)), kad kiti galėtų mokytis.

• Standartų kūrimo institucijos (IEEE, ISO, W3C ir kt.) turėtų įtraukti kodavimą į esamus DI etikos ir saugos standartus. Pavyzdžiui, ISO vykdomas darbas dėl DI valdymo (ISO/IEC 38507) ir DI gyvavimo ciklo (ISO/IEC 5338) galėtų aiškiai nurodyti kodo generavimą. W3C turi parengtą etinių principų projektą žiniatinklio mašininio mokymosi (Web ML) srityje (www.w3.org) – tai galėtų būti išplėsta skyriumi apie programavimo naudojimą. Turėtų atsirasti lengvas „praktikos kodeksas“ DI priklausomoms kūrimo komandoms, panašiai kaip egzistuoja saugaus kūrimo standartai (pvz., OWASP) saugumui.

Trumpai tariant, kelias į priekį yra socialinis-techninis. Kaip atvirojo kodo bendruomenės sukūrė kodavimo standartus ir peržiūros kultūras, taip ir besiformuojančiai DI kodavimo sričiai reikia bendrų normų. Bendri veiklos planai (pvz., pramonės konsorciumai dėl DI kodo saugumo) ir skaidrumas (etalonų ir gedimų atvejų publikavimas) sujungs visus į vieną puslapį.

8. Kam naudinga ir kaip pradėti

Svarbiausia, DI pagelbėtas kodavimas skirtas ne tik ekspertams kūrėjams. Šios priemonės gali demokratizuoti programavimą. Pradedantieji ir dalykinės srities ekspertai gali naudoti DI, kad pradėtų projektus, kuriems niekada neturėtų laiko koduoti rankiniu būdu. Pavyzdžiui, rinkodaros analitikas galėtų paprašyti DI parašyti duomenų ataskaitų scenarijų, užuot mokęsis Python nuo nulio. Menininkas galėtų prototipuoti programėlės vartotojo sąsają, nupiešdamas užklausą. Kiekvienu atveju DI sumažina kūrybos barjerą.

Norėdami pradėti naudoti šiuos įrankius, vadovaukitės tuo pačiu lanksčiu, iteraciniu darbo srautu, kurį naudoja profesionalios komandos:

1. Apibrėžkite aiškų tikslą arba specifikaciją. Pradėkite konkrečiai nurodydami, ko norite. Tai gali būti natūralios kalbos funkcijos aprašymas arba paprastas žingsnių eskizas. Programuotojams pakanka net punktais nurodyto sąrašo ar vartotojo istorijų.
2. Naudokite DI asistentą kodo projektui parengti. Paleiskite DI kodavimo įrankį (jų yra daug: internetiniai pokalbių robotai ar IDE plėtiniai) ir paprašykite jo įdiegti specifikaciją. Pavyzdžiui, galite įvesti „Sukurkite Python funkciją, kuri nuskaito CSV failą ir atvaizduoja duomenų taškus.“ DI sugeneruos pirmąją versiją.
3. Patikrinkite ir patikslinkite. Svarbiausia, paimkite DI rezultatą ir išbandykite jį. Jei tai kodas, paleiskite jį savo aplinkoje. Parašykite arba automatiškai sugeneruokite keletą paprastų testų: ar jis duoda teisingus rezultatus baziniais atvejais? Jei kas nors nepavyksta (tai dažnai nutinka iš pirmo karto), pateikite atsiliepimą DI: pavyzdžiui, paryškinkite nesėkmingą atvejį ir paprašykite pataisyti kodą. Daugelis įrankių leidžia iteratyviai teikti užklausas arba „daugialypį“ redagavimą.
4. Paprašykite paaiškinimų ir dokumentacijos. Naudokite DI, kad po fakto sukurtumėte dokumentacijos eilučių (docstring) arba komentarus. Tai padeda jums, (naujam) koduotojui, suprasti, kas buvo padaryta. Taip pat galite paprašyti DI nurodyti galimas problemas ar pasiūlyti patobulinimų.
5. Palaipsniui didinkite sudėtingumą. Kai paprasti scenarijai veikia, galite pabandyti mažą projektą (pvz., užduočių programėlę, duomenų analizės konvejerį). Padalinkite projektą į dalis: paprašykite DI kiekvieno komponento (duomenų bazės schema, sąsaja, verslo logika) po vieną. Vertinkite tai kaip porinį programavimą, kur DI yra jūsų jaunesnysis partneris.

Pirmas kitas žingsnis: Pasirinkite pradedantiesiems tinkamą DI kodavimo įrankį ir atlikite nedidelį eksperimentą. Pavyzdžiui, naudokite sąsają, tokią kaip GPT-4 (su kodavimo galimybėmis) arba nemokamą plėtinį savo kodo redaktoriuje. Duokite jam trivialią užduotį („rūšiuoti sąrašą“, „sukurti grafiką“, „hello world“ tinklalapį) ir pažiūrėkite, ką jis sugeneruos. Tada perskaitykite kodą – net neturėdami kodavimo patirties, atkreipkite dėmesį į struktūrą. Paleiskite jį ir atkreipkite dėmesį į visas klaidas. Tada pakartokite: patikslinkite savo užklausą (galbūt pridėkite daugiau detalių ar apribojimų) ir iš naujo sugeneruokite. Laikui bėgant, išmoksite efektyviai bendrauti su įrankiu ir nukreipti jį teisingų sprendimų link.

Nauji koduotojai turėtų atsiminti: DI yra galingas asistentas, o ne orakulas. Visada patikrinkite jo darbą ir naudokite tai kaip mokymosi galimybę. Parašykite savo testus DI kodui, paleiskite juos ir užduokite papildomų klausimų, kol būsite tikri. Šis „patikrink ir tada pasitikėk“ įprotis yra būdas, kaip visi – pradedantieji ar ekspertai – turėtų saugiai kurti su DI.

Išvada

Autonominių kodavimo įrankių atsiradimas yra lūžio taškas, tačiau norint visapusiškai pasinaudoti privalumais, turime susidurti su atviromis problemomis, kurias atskleidė ankstyvieji diegimai. Kalbant apie patikimumą, matome, kad kodo asistentai daro daugiau klaidų nei žmonės, todėl tyrimai turi būti sutelkti į klaidų aptikimą ir patikimą generavimą. Planavime matome, kad agentai suklumpa ilgalaikiuose, daugiaetapiuose projektuose, todėl mums reikia naujų architektūrų ir etalonų sudėtingiems darbo procesams. Kalbant apie tikrinamumą, suprantame, kad mums reikia formalių specifikacijų ir testavimo palaikymo, integruoto į patį DI kodavimo procesą. O kalbant apie valdymą, įmonės ir reguliavimo institucijos skuba nustatyti taisykles, kad DI kodas būtų skaidrus, saugus ir atskaitomas.

Per ateinančius 18 mėnesių pažanga kiekvienoje iš šių sričių bus esminė. Sukūrus griežtus etalonus (nuo projektų planavimo iššūkių iki DI sukeltų klaidų patikrinimo), integravus formaliuosius metodus į DI kodavimo procesus ir užmezgus bendradarbiavimą tarp disciplinų, galime panaikinti atotrūkį tarp įspūdingų demonstracijų ir realaus pasaulio patikimumo. Vizija yra aiški: DI kodavimo ekosistema, kurioje net pradedantieji gali saugiai kurti programinę įrangą, ir kur DI generuojamas kodas yra toks pat patikimas, kaip ir žmogaus sukurtas kodas. Šios vizijos įgyvendinimui reikės formuoti tiek technologiją, tiek su ja susijusias praktikas. Sutelkus tyrimus ir plačios bendruomenės pastangas, naujos kartos DI įrankiai gali iš tiesų atverti kodavimą kiekvienam – pradedant šiandien.

**`