Pētījumu prioritātes nākamajiem 18 mēnešiem: Kur autonomajai kodēšanai vajadzētu attīstīties tālāk

Pētījumu prioritātes: Autonomās kodēšanas nākamie 18 mēneši

Ar AI darbināmi kodēšanas asistenti jau tagad pārveido programmatūras izstrādi. Līdz 2025. gada beigām tādi rīki kā GitHub Copilot un AI tērzēšanas roboti tiek izmantoti ikdienā lielākajā daļā izstrādātāju, un pat ne-programmētāji var izveidot koda prototipus ar vienkāršiem uzvedņiem. Google izpilddirektors atzīmē, ka šī tendence – ko bieži dēvē par “vibe coding” – padara programmēšanu pieejamāku netehniskajam personālam (www.itpro.com). Tomēr reālās pasaules ieviešana ir atklājusi svarīgas nepilnības. AI ģenerētais kods bieži satur smalkas kļūdas, nedarbojas sarežģītos projektos un rada atbildības un politikas jautājumus. Lai pārietu no laboratorijas demonstrācijām uz uzticamām ražošanas sistēmām, mums ir nepieciešami mērķtiecīgi pētījumi četrās jomās: uzticamību, ilgtermiņa plānošanu, pārbaudāmību un sociotehnisko pārvaldību. Zemāk mēs izklāstām galvenās neatrisinātās problēmas un ierosinām pētījumu programmas, salīdzinošos kritērijus un sadarbības veidus, lai tās risinātu.

1. Uzticamība un koda kvalitāte

Liela problēma ir pamata uzticamība: AI asistentu rakstītais kods joprojām satur ievērojami vairāk kļūdu nekā cilvēku rakstītais kods. Piemēram, 470 GitHub pieprasījumu analīze atklāja, ka AI rakstītajiem PR bija par 1,7 reizēm vairāk problēmu nekā cilvēku rakstītajiem (www.itpro.com). Vidēji AI PR izraisīja ~10,8 problēmas (loģikas kļūdas, nosaukumu vai formatēšanas problēmas, drošības nepilnības utt.) salīdzinājumā ar ~6,5 cilvēku PR (www.itpro.com). Īpaši jāatzīmē, ka AI autorētajā kodā bija smagāks “astes” smago kļūdu (loģikas kļūdas un drošības ievainojamības parādījās gandrīz divas reizes biežāk nekā cilvēku kodā) (www.itpro.com). Praksē komandas, kas izmanto AI rīkus, ir ziņojušas par pārsteigumiem: kods, kas izolēti izskatās pareizs, bet neizdodas integrācijā vai satur slēptas nepilnības. Patiešām, visaptverošs koda ģenerēšanas rīku apsekojums novēro, ka esošie salīdzinošie kritēriji neuztver ražošanā novērotos kļūdu veidus – halucinētas API izsaukumus, pretrunīgu nosaukumu piešķiršanu vai smalkas loģikas kļūdas, kas paslīd garām vienības testiem (doi.org). Īsāk sakot, AI var ģenerēt strādājošus koda fragmentus, taču šie fragmenti bieži vien nav gatavi ražošanai (doi.org).

Izstrādātāju pieredze atspoguļo šo neuzticību. Liels SonarSource pētījums (ko ziņoja nozares prese) atklāja, ka, lai gan 72% inženieru ikdienā izmanto AI rīkus, lai uzrakstītu līdz pat 42% koda, satriecoši 96% atzīst, ka pilnībā neuzticas AI ģenerētajam rezultātam (www.itpro.com). Tomēr mazāk nekā puse komandu vienmēr pārskata AI ģenerēto kodu pirms apstiprināšanas (www.itpro.com). Šī plaisa – liela lietošana, bet zema uzticība – noved pie tā, ko eksperti sauc par “verifikācijas parādu.” Bez labākas uzticamības organizācijas riskē ieviest grūti atklājamas kļūdas un tehnisko parādu ikreiz, kad tās izmanto AI kodēšanas īsceļus (www.itpro.com).

Pētījumu programma: Mums ir nepieciešama sistemātiska AI koda kļūdu modeļu izpēte un jaunas metodes to mazināšanai. Idejas ietver automatizētu AI pārbaudi: statisko analizatoru vai sekundāro modeļu integrēšanu, kas skenē AI rezultātus, meklējot biežākās kļūdas (līdzīgi kā otrs recenzents). Labāki LLM apmācības mērķi varētu koncentrēties uz stabilitāti – piemēram, apmācība, izmantojot kļūdainus pret tīru kodu piemērus, lai iemācītu modelim dot priekšroku drošākiem risinājumiem. Pētniekiem vajadzētu analizēt, kādi koda veidi (algoritmi, I/O, drošības kritiskie) apgrūtina AI iekšējās heuristikas, un izstrādāt specializētus aizsardzības līdzekļus. Piemēram, agrīnā darbā tika atzīmēts, ka AI rīki pārmērīgi izmanto riskantus īsceļus (cietkodētas paroles, neefektīvas cilpas utt.) (www.businesswire.com) (www.infoworld.com). Mums ir jākodificē šie kļūdu veidi.

Izglītojoši risinājumi arī var palīdzēt: kā uzsver kopienas vadlīnijas, AI rīki var tikai palīdzēt – cilvēkiem ir jāpārbauda (firefox-source-docs.mozilla.org) (chromium.googlesource.com). Lai to veicinātu, nākotnes rīki varētu automātiski ģenerēt brīdinājumus vai pat atteikties apstrādāt uzdevumus bez cilvēka apstiprinājuma. Salīdzinošajai novērtēšanai vajadzētu mainīties: pāriet no “vai šis kods kompilējas” uz “cik smalku problēmu paliek”. Piemēram, parādās koda pārskatīšanas AI modeļi, kas īpaši mēra kļūdu noteikšanas veiktspēju (docs.factory.ai). Kopienas centieni radīt publisku datu kopu ar reālām AI un cilvēka koda izmaiņām (ar anotētiem defektiem) – līdzīgi kā CodeRabbit PR pētījums – ļautu pētniekiem sekot uzticamības progresam.

2. Ilgtermiņa plānošana un uzturēšana

AI koda ģeneratori izceļas ar maziem, pašpietiekamiem uzdevumiem, taču lielos projektos atklājas to ierobežojumi. Reālā programmatūra laika gaitā attīstās, ar mainīgām prasībām, vairākiem failiem un arhitektūras lēmumiem, kas jāpārvalda. Aptaujas atzīmē, ka “pareizu izolētu funkciju ģenerēšana kvalitatīvi atšķiras no saskaņotu arhitektūras lēmumu uzturēšanas lielā koda bāzē” (doi.org). Praksē pat vismodernākie modeļi cīnās ar daudzpakāpju, daudzfailu uzdevumiem. Divi nesenie salīdzinošie kritēriji izceļ šo plaisu:

• RoadmapBench (2026. gada maijs) novērtē “ilgtermiņa” uzlabojumus reālos atvērtā koda projektos. Katrā uzdevumā aģentam tiek dota projekta pamatversija un ieviešamo funkciju saraksts, ar ~3700 mainītām rindām vairāk nekā 50 failos. Pat Claude-Opus-4.7, viens no spēcīgākajiem modeļiem, atrisināja tikai ~39% uzdevumu, un citi modeļi kritās līdz pat 5% (papers.cool). Turpretim vienkārši vienreizēji kļūdu labojumi nodrošina gandrīz perfektu AI veiktspēju. RoadmapBench autori secina, ka “ilgtermiņa programmatūras izstrāde joprojām ir lielākoties neatrisināta problēma.” (papers.cool)

• SlopCodeBench (2026) pēta iteratīvo izstrādi. Aģentiem tika dots uzdevums un izveidots kods, pēc tam 20 kārtās uzdevuma specifikācija mainījās, liekot kodam attīstīties. Rezultāts: lai gan visas starpposma versijas izturēja esošos testus, AI ģenerētās koda bāzes kļuva 2,2 reizes apjomīgākas un daudz grūtāk uzturamas nekā cilvēku uzturētais kods (www.techradar.com). Patiesībā neviens no labākajiem modeļiem neatrisināja visu secību: veiksmes rādītāji kritās līdz ~0,5% līdz galīgajam kontrolpunktam. Tas liecina, ka mazas dizaina kļūdas uzkrājas ar AI palīdzību, kavējot turpmākās modifikācijas (www.techradar.com).

Šie atklājumi liecina, ka pētījumiem jākoncentrējas uz plānošanu un sadalīšanu. AI sistēmām nevajadzētu vienkārši “rakstīt kodu” atbilstoši uzvedumam, bet plānot daudzpakāpju stratēģijas. Viena jauna ideja ir plānot un izpildīt: ļaut modelim vispirms izklāstīt dizainu vai soļu secību, pēc tam ģenerēt kodu katram solim (crabtalk.ai). Patiesībā kodēšanas aģentu (Claude Code, GitHub Copilot utt.) analīzes atklāj, ka plānošanas atdalīšana no izpildes (un plāna atklāšana lietotājam) dramatiski uzlabo veiktspēju sarežģītos uzdevumos (crabtalk.ai). Pētījumos jāizstrādā jaunas arhitektūras: piemēram, ligzdoti aģenti, kur “pārvaldnieks” LLM lielo problēmu sadala apakšuzdevumos darba LLM. Nepieciešami arī ilgtermiņa atmiņas mehānismi: nākotnes modeļiem vajadzētu atcerēties kodu, kas ģenerēts agrāk sesijā, pat ārpus konteksta loga.

Salīdzinošie kritēriji: Kopienai vajadzētu definēt salīdzinošos kritērijus, kas atspoguļo reālo izstrādes darbu. Pārsniedzot RoadmapBench, mums ir nepieciešami uzdevumi, kas aptver vairākas valodas un integrācijas izaicinājumus (frontend/backend, datubāzes utt.). Simulēti komandas projekti pārbaudītu, kā AI un cilvēki sadarbojas izlaides laikā. Aizgūstot idejas no programmatūras inženierijas, salīdzinošie kritēriji varētu mērīt ne tikai pareizību, bet arī uzturēšanu (cik viegli ir pievienot jaunu funkciju?), veiktspēju (vai AI kods pasliktinās, attīstoties?), un integrāciju (vai tas atbilst esošajām stila konvencijām?). Piemēram, salīdzinošie kritēriji varētu sākt ar esošu koda bāzi un lūgt aģentam ieviest virkni funkciju pieprasījumu vai refaktoringu, ar periodiskām pārbaudēm. Nākamo 18 mēnešu laikā šādu atklātu izaicinājumu (iespējams, izmantojot akadēmiski-industriālus konkursus) radīšana vadīs pētījumus daudzpakāpju kodēšanā.

3. Pārbaudāmība un formālās saskarnes

AI asistentiem mēģinot veikt kritiskākus uzdevumus, pareizības nodrošināšana kļūst būtiska. Pārbaudāmība nozīmē koda sasaistīšanu ar precīzām specifikācijām vai testu komplektiem, lai mēs varētu būt pārliecināti, ka tas dara to, ko vēlamies. Klasiskajā inženierijā pirms kodēšanas tiek uzrakstīta formāla specifikācija vai rūpīgi testi. Kā mēs šo domāšanas veidu ieviestu AI vadītā kodēšanā?

Viena iespēja ir “slēgtās cilpas” ģenerēšana. Nesenie darbi ierosina, ka AI ģenerētais kods, tā docstring un visas formālās anotācijas ir jāpārbauda attiecībā uz konsekvenci. Piemēram, Clover pieeja automātiski ģenerē formālas specifikācijas (izmantojot tādas valodas kā Dafny) kopā ar kodu un pēc tam izmanto pierādījumu rīkus, lai noraidītu nekonsekventus risinājumus (theory.stanford.edu). Agrīnajos testos tas atklāja visas nepareizās programmas mācību grāmatu līmeņa datu kopā. Līdzīgi, AutoACSL izmanto statisko analīzi, lai pamudinātu LLM rakstīt precīzas funkciju līgumu (priekš- un pēccieprasījumu) un pēc tam tās pārbauda ar Frama-C (papers.cool). Atgriezeniskā saite ar neapmierinātiem nosacījumiem dramatiski uzlaboja pierādāmi pareiza koda procentuālo daudzumu. Šie piemēri liecina, ka formālo metožu integrēšana koda ģenerēšanas solī var pārvērst nekontrolētu AI minējumu par pārbaudītu programmu.

Bez formālās matemātikas mums ir vajadzīgas arī labākas saskarnes starp neformālām specifikācijām, testiem un kodu. Šodien ir ierasts aprakstīt funkciju angļu valodā un cerēt, ka AI darīs pareizo lietu. Taču mums vajadzētu arī likt AI ģenerēt vai lūgt testa gadījumus, tipu anotācijas un dizaina komentārus. Piemēram, uzvedums varētu vispirms lūgt modelim aprakstīt algoritmu vai invariantus dabīgā valodā vai pseidokodā, un tikai tad to kodēt. Vai arī mēs varētu izmantot līguma-pirmā izstrādi: rakstīt vienības testus (vai īpašību testus), kuriem AI jāatbilst. Šo ideju aptuvenās skices ir izrādījušās daudzsološas: pat dažu uz piemēriem balstītu testu ģenerēšana var novirzīt modeli no triviāliem risinājumiem.

Salīdzinošie kritēriji: Jauniem salīdzinošajiem kritērijiem vajadzētu ietvert formālas pārbaudes problēmas. Piemēram, mēs varētu pievienot uzdevumus, kur “pareizība” tiek pārbaudīta ar teorēmu pierādītāju vai simbolisku pārbaudītāju, nevis tikai vienības testiem. Vērtīgas būtu lietotāju stāstu datu kopas ar LTL/TLA+ vai Alloy specifikācijām un atbilstošu kodu. Izglītībā tādi konkursi kā TLA+ modeļa pārbaudes izaicinājums liecina, ka specifikāciju izstrāde ir grūta – viens pētījums atklāja, ka pašreizējie LLM sasniedz tikai ~8% semantisko pareizību vienkāršās TLA+ specifikācijās (papers.cool). Atvērtā koda projekti varētu plašāk izlaist specifikācijas valodas (savdabīgu kodēšanas apliecinājumu). Standartizētus formātus (YAML, JSON) API specifikācijām vai datu shēmām AI varētu izmantot, lai saskaņotu kodu ar paredzēto uzvedību.

4. Sociotehniskā pārvaldība un uzticēšanās

Visbeidzot, autonomā kodēšana rada cilvēka un politikas jautājumus. Kas ir atbildīgs par AI kodu? Kā mēs nodrošinām drošību, autortiesību atbilstību un atbildību? Vairākas organizācijas ir sākušas to risināt, taču atklātie jautājumi joprojām pastāv.

Izstrādātāju prakse: Kā minēts, nozares aptaujas liecina par uzticības plaisu. Izstrādātāji zina, ka viņiem vajadzētu pārskatīt AI rezultātus, taču bieži vien to izlaiž, ja tas ir vieglāk, radot nepārvaldītu risku (www.itpro.com). Atbildot uz to, lieli projekti ir noteikuši skaidrus noteikumus. Piemēram, OpenInfra Foundation atļauj AI palīdzību tikai tad, ja apstiprinājumi ir marķēti ar “Assisted-By:” vai “Generated-By:” atzīmi (openinfra.org). Google Chromium projekts līdzīgi prasa, lai autori pilnībā izprot jebkuru AI ieteikto kodu, pretējā gadījumā viņi zaudē apstiprinājuma privilēģijas (chromium.googlesource.com). Mozilla Firefox politika tieši nosaka: “AI var palīdzēt, taču atbildība vienmēr paliek pie cilvēka, kas veic izmaiņas” (firefox-source-docs.mozilla.org). Pat NumPy projekts brīdina, ka jums jāspēj izskaidrot jebkuru iesniegto kodu, neatkarīgi no tā, vai to rakstījis AI (numpy.org). Šīs politikas uzsver, ka tikai tehniskie rīki nav pietiekami – mums ir nepieciešami arī skaidri darba procesi un kultūra.

Regulēšana un standarti: Plašākā mērogā valdības un standartu iestādes sāk apzināties situāciju. ES pabeidz Vispārējas nozīmes AI prakses kodeksu, kas prasīs caurskatāmību un drošības pasākumus no AI modeļu nodrošinātājiem (digital-strategy.ec.europa.eu). Lai gan tas nav specifisks kodēšanai, tas signalizē par stingrāku uzraudzību attiecībā uz apmācības datu licencēm un modeļa izskaidrojamību – abas ir ļoti svarīgas, ja jūsu koda asistents izmantoja ar autortiesībām aizsargātu kodu. Līdzīgi, ISO un IEEE ir sākuši veidot AI standartus pārvaldībai un ētikai, lai gan tikai daži tieši attiecas uz koda ģenerēšanu. AI akts (ES) un gaidāmās ASV vadlīnijas, visticamāk, ietekmēs to, kā uzņēmumi pārbauda AI kodu iekšēji.

Nepieciešama sadarbība: Šo sociotehnisko plaisu aizpildīšanai būs nepieciešami kopīgi centieni. Akadēmiskās aprindas var pētīt, kā AI rīki ietekmē komandu produktivitāti, ievainojamību atklāšanu un licencēšanu; industrija var dalīties ar anonimizētiem datiem par reāliem ar AI saistītiem incidentiem; standartu iestādes (piemēram, W3C, IEEE) var iekļaut kodēšanas scenārijus ētikas AI vadlīnijās. Piemēram, darbnīcas varētu apvienot SAT-EL (programmatūras nodrošināšanas) ekspertus ar ML speciālistiem, lai definētu AI koda drošības novērtēšanas kritērijus. Vadlīnijas varētu attīstīties par standartiem (piemēram, “IEEE 8201: AI atbalstīts programmatūras process”), nodrošinot organizācijām kopēju ietvaru. Nākamo 18 mēnešu laikā vienprātības veidošana par labāko praksi – izmantojot baltās grāmatas, konsorcijas vai atvērtā koda politikas veidnes – palīdzēs komandām atbildīgi ieviest šos rīkus.

5. Pētījumu un salīdzinošo kritēriju programma

Apkopojot, mēs ierosinām šādus konkrētus soļus pētniecības kopienai:

• Paplašināti salīdzinošie kritēriji: Izstrādāt salīdzinošo kritēriju kopumu, kas imitē reālus programmatūras projektus. Piemēram, vairāku moduļu ietvaru (tīmekļa lietojumprogrammas, API, iegultās sistēmas), kur AI jāievieš jaunas funkcijas un pēc tam tās jāuztur. Iekļaut mainīgās specifikācijas (simulējot mainīgās prasības). Mērīt ne tikai testu izturēšanas rādītājus, bet arī koda sarežģītību, lasāmību, drošības metrikas un pārskatīšanas darba slodzi. Sadarboties ar nozari, lai iegūtu reālas kļūdu labojumu vēstures un funkciju pieprasījumus kā salīdzinošo kritēriju uzdevumus.

• Kļūdu taksonomijas pētījums: Sistemātiski kategorizēt AI ieviesto kļūdu veidus. CodeRabbit ziņojums sniedza sākotnējo sadalījumu (loģikas kļūdas, nosaukumu problēmas utt.) (www.infoworld.com). Lielāks akadēmisks pētījums varētu savākt PR datus un klasificēt AI pret cilvēka kļūdas. Tas vadītu jaunus modeļu zudumus (piemēram, papildu svars drošībai) un automatizētus detektorus (rīkus, kas atzīmē tipiski AI kļūdainus modeļus).

• Plānošanas un vairāku aģentu pētījumi: Izpētīt arhitektūras, piemēram, plānotāja/izpildītāja aģentus. Izpētīt, kā dot AI sistēmām kādu atmiņas formu pāri sesijām vai nodrošināt hierarhisku plānošanu. Sadarboties ar esošajiem darbiem aģentūrā AI un robotikā (pārveidojot daudzpakāpju spriešanas metodes kodam).

• Formālo metožu integrācija: Ieguldīt pētījumos, piemēram, Clover un AutoACSL, kas saista programmas sintēzi un pierādījumus. Mudināt formālo metožu pētniekus sadarboties ar NLP/ML grupām. Piemēram, akadēmiskie konkursi varētu apvienot LLM koda asistentus ar pierādītājiem kopīgos uzdevumos. Izveidot konkursus AI ģenerētiem pierādījumiem vai līgumu secinājumiem.

• Pārvaldības ietvari: Sociālo zinātņu pētījumi par komandu praksi un atbildību. Piemēram, veikt izstrādātāju pētījumus: dot komandām AI rīkus un novērot, kā tās pārskata un atkļūdo. Juridiskie pētījumi par intelektuālo īpašumu: kā atzīmē viens emuārs, “Copilot autortiesību problēma” (nelicencēts kods) ir atklāts jautājums (www.systemshardening.com). Standartu iestādēm vajadzētu izstrādāt skaidras vadlīnijas attiecībā uz datu licencēšanu un attiecināšanu AI kodam.

• Rīki un saskarnes: Visbeidzot, izveidot rīku prototipus, kas demonstrē labāko praksi. Piemērs: AI kodēšanas IDE spraudnis, kas automātiski veic statisko analīzi vai testus jebkuram AI ģenerētajam kodam un brīdina lietotāju. Vai CLI, kas iezīmē visas AI atbalstītās sadaļas koda bāzē. Mudināt atvērtā koda projektus pieņemt “AI izmantots” nozīmītes vai commit-message konvencijas. Šos neformālos standartus vēlāk var formalizēt.

Definējot kopienas salīdzinošos kritērijus un rīkojot vairāku institūciju izaicinājumus (piemēram, AI kodēšanas hakatonu, lai sasniegtu noteiktus drošības vai uzturēšanas mērķus), mēs varam sekot progresam. Iedomājieties, kā ImageNet virzīja redzi: mums ir nepieciešams kopīgs “ImageNet kodam”, kas atspoguļo reālo attīstību. Agrīnie centieni (RoadmapBench, SlopCodeBench, Sigmabench (sigmabench.com)) norāda ceļu, taču nākamreiz mums tie ir jāpaplašina un jāpadara plaši pieejami.

6. Formālās saskarnes: Specifikācijas, testi un kods

Centrālā iespēja ir ciešāka specifikāciju un testu integrācija kodēšanas ciklā. Tradicionālajā izstrādē specifikācija apraksta, ko kodam vajadzētu darīt, un testi to pārbauda. AI rīki var palīdzēt savienot šos elementus. Piemēram, daudzsološa prakse ir specifikāciju vadīta ģenerēšana: vispirms uzrakstīt (iespējams, neformālu) specifikāciju, pēc tam likt AI to kodēt. Vēl labāk, specifikāciju varētu izstrādāt kopā ar AI. Piemēram, jautāt asistentam: “Ģenerējiet vienības testus šai prasībai,” un pēc tam “Izmantojiet šos testus, lai validētu kodu.” Tas rada formālu saskarni: dabīgās valodas specifikācija, tās implicētie testi un kods veido ciešu trijstūri.

Pētniecības jomā varētu definēt standartizētu formātu specifikācijām (piemēram, YAML vai JSON shēmu, kas apraksta funkcionalitāti) un pieprasīt AI sistēmām to patērēt. Varētu integrēt tādus rīkus kā TLA+, Alloy vai BDD stila rīkus (Cucumber): iedomājieties, ka sakāt AI: “lūdzu, ģenerējiet kodu, kas atbilst šim TLA+ modelim.” Lai gan pašreizējie LLM nav izcili TLA+ rakstīšanā no nulles (papers.cool), ir vērts izpētīt cilvēka rakstītas abstraktas specifikācijas apvienošanu ar AI papildinātu koda ģenerēšanu. Mērķis ir padarīt vieglu komandām radīt izpildāmu specifikāciju (pat ja neformālu), kuru AI respektē. Formālie testi pēc tam varētu tikt automātiski ģenerēti: nesenie darbi liecina, ka GPT modeļi var radīt uz īpašībām balstītus testus, ņemot vērā funkcijas uzvedības aprakstu.

Ambiciozāk, mēs varam izveidot formālās specifikācijas veidnes. Mākoņdatošanas izvietošanai vai drošības kritiskam kodam definēt veidni (piemēram, “Lietotāja autentifikācijas plūsma” ar laukiem). AI aizpilda veidni un ģenerē kodu; validētājs pārbauda līgumu. Nodrošinot šīs saskarnes, mēs pārveidojam kodēšanu no melnas kastes par kontrolētāku cauruļvadu. Iniciatīvas, piemēram, AI rīki TLA+ vai LLM-uz-specifikāciju tulkošana (notiek dažās pētniecības grupās), ir agrīni piemēri. Praksē pat daļēja ieviešana (lūdzot AI izvadi komentārus vai tipu parakstus) var uzlabot pareizību.

Kā pirmais solis izstrādātājiem: iekļaujiet vienkāršas specifikācijas-testu cilpas jau tagad. Piemēram, ja izmantojat ChatGPT, sāciet sesiju, rakstot “Mēs vēlamies funkciju, kas veic X, vispirms uzrakstiet testus.” Pēc tam lūdziet tai ģenerēt implementāciju. Pat bez izsmalcinātiem formāliem rīkiem tas nodrošina disciplīnu, kurā AI vienmēr ražo kodu ar pavadošo pārbaudi. Laika gaitā šis ieradums var tikt formalizēts AI kodēšanas standartos.

7. Sadarbība: Akadēmiskās aprindas, industrija un standarti

Šo mērķu sasniegšanai ir nepieciešama plaša sadarbība:

• Akadēmiskās aprindas var dot ieguldījumu, veidojot un daloties ar datiem un salīdzinošajiem kritērijiem, kā arī publicējot stingrus novērtējumus. Universitātēm vajadzētu sadarboties ar uzņēmumiem, lai iegūtu reālas koda bāzes testēšanai. Pētniecības laboratorijas var rīkot atklātus izaicinājumus (ar balvām) par tādiem uzdevumiem kā ilgtermiņa koda kvalitāte vai verificēta koda ģenerēšana.

• Industrijai jānodrošina atgriezeniskās saites cilpas. Uzņēmumiem, kas ievieš AI kodēšanas rīkus, vajadzētu anonīmi dalīties ar kļūdu statistiku, dalībnieku pieredzi un funkciju pieprasījumiem. Tehnoloģiju uzņēmumi var arī finansēt “AI kodēšanai” darbnīcas vai sekcijas konferencēs (piemēram, ICSE, FSE). Viņi var atvērt daļu savu politiku (kā Google darīja ar Chromium AI politiku (chromium.googlesource.com)), lai citi varētu mācīties.

• Standartu iestādēm (IEEE, ISO, W3C utt.) vajadzētu iekļaut kodēšanu esošajos AI ētikas un drošības standartos. Piemēram, ISO notiekošajā darbā pie AI pārvaldības (ISO/IEC 38507) un AI dzīves cikla (ISO/IEC 5338) varētu skaidri norādīt koda ģenerēšanu. W3C ir izstrādāts tīmekļa mašīnmācīšanās ētikas principu projekts (www.w3.org) – to varētu paplašināt ar sadaļu par programmēšanas izmantošanu. Jāparādās vieglam “prakses kodeksam” AI atkarīgām izstrādes komandām, līdzīgi kā drošības jomā pastāv drošas izstrādes standarti (piemēram, OWASP).

Īsāk sakot, ceļš uz priekšu ir sociotehnisks. Tāpat kā atvērtā koda kopienas veidoja kodēšanas standartus un pārskatīšanas kultūras, arī jaunajā AI kodēšanas jomā ir vajadzīgas kopīgas normas. Kopīgi ceļveži (piemēram, nozares konsorciji par AI koda drošību) un caurskatāmība (salīdzinošo kritēriju un kļūdu gadījumu publicēšana) visus novedīs uz vienas lapas.

8. Kam tas nāk par labu un kā sākt

Būtiski, AI atbalstītā kodēšana nav paredzēta tikai ekspertiem izstrādātājiem. Šie rīki var demokratizēt programmēšanu. Iesācēji un jomas eksperti var izmantot AI, lai uzsāktu projektus, kuriem viņiem nekad nebūtu laika kodēt ar rokām. Piemēram, mārketinga analītiķis varētu lūgt AI uzrakstīt datu atskaišu skriptu, nevis mācīties Python no nulles. Mākslinieks varētu izveidot lietotnes UI prototipu, uzmetot uzvedni. Katrā gadījumā AI samazina radīšanas šķēršļus.

Lai sāktu ar šiem rīkiem, sekojiet tai pašai ātrajai, iteratīvajai darba plūsmai, ko izmanto profesionālās komandas:

1. Definējiet skaidru mērķi vai specifikāciju. Sāciet ar to, ka konkrēti izklāstāt, ko vēlaties. Tas var būt dabīgās valodas apraksts par funkciju vai vienkārša soļu skice. Programmētājiem pat saraksts ar aizzīmēm vai lietotāju stāstiem var kalpot.
2. Izmantojiet AI asistentu koda izveidei. Palaidiet AI kodēšanas rīku (daudzi ir pieejami: tiešsaistes tērzēšanas roboti vai IDE paplašinājumi) un lūdziet to ieviest specifikāciju. Piemēram, jūs varētu ierakstīt “Izveidojiet Python funkciju, kas nolasa CSV un attēlo datu punktus.” AI ģenerēs pirmo versiju.
3. Pārbaudiet un pilnveidojiet. Būtiski, paņemiet AI rezultātu un pārbaudiet to. Ja tas ir kods, palaidiet to savā vidē. Uzrakstiet vai automātiski ģenerējiet dažus vienkāršus testus: vai tas sniedz pareizus rezultātus pamata gadījumos? Ja kaut kas neizdodas (tas bieži notiks pirmajā mēģinājumā), sniedziet atgriezenisko saiti AI: piemēram, izceliet kļūdaino gadījumu un lūdziet to labot kodu. Daudzi rīki atļauj iteratīvu uzvedumu vai “vairāku pagriezienu” rediģēšanu.
4. Lūdziet paskaidrojumus un dokumentāciju. Izmantojiet AI, lai pēc tam izveidotu docstrings vai komentārus. Tas palīdz jums, (jaunajam) kodētājam, saprast, kas tika darīts. Varat arī lūgt AI norādīt iespējamās problēmas vai ieteikt uzlabojumus.
5. Pakāpeniski palieliniet sarežģītību. Kad vienkārši skripti darbojas, varat mēģināt izveidot nelielu projektu (piemēram, uzdevumu lietotni, datu analīzes cauruļvadu). Sadaliet projektu daļās: lūdziet AI katru komponentu (datubāzes shēmu, priekšgala, biznesa loģiku) pa vienai. Uztveriet to kā pāru programmēšanu, kur AI ir jūsu jaunākais partneris.

Pirmais nākamais solis: Izvēlieties iesācējiem draudzīgu AI kodēšanas rīku un veiciet nelielu eksperimentu. Piemēram, izmantojiet saskarni, piemēram, GPT-4 (ar koda iespējām) vai bezmaksas paplašinājumu savā koda redaktorā. Dodiet tam triviālu uzdevumu (“sakārtot sarakstu”, “izveidot grafiku”, “hello world tīmekļa lapa”) un skatieties, ko tas rada. Pēc tam izlasiet kodu – pat bez kodēšanas pieredzes, aplūkojiet struktūru. Palaidiet to un atzīmējiet visas kļūdas. Pēc tam atkārtojiet: pilnveidojiet savu uzvedni (varbūt pievienojiet vairāk detaļu vai ierobežojumu) un ģenerējiet no jauna. Laika gaitā jūs iemācīsities efektīvi sazināties ar rīku un virzīt to uz pareiziem risinājumiem.

Jauniem kodētājiem jāpatur prātā: AI ir spēcīgs palīgs, nevis orākuls. Vienmēr pārbaudiet tā darbu un izmantojiet to kā mācību iespēju. Uzrakstiet savus testus AI kodam, palaidiet tos un uzdodiet papildu jautājumus, līdz esat pārliecināts. Šis “pārbaudīt-un-pēc tam-uzticēties” ieradums ir veids, kā ikvienam – iesācējam vai ekspertam – vajadzētu droši veidot ar AI.

Secinājums

Autonomo kodēšanas rīku pieaugums ir pagrieziena punkts, taču, lai pilnībā izmantotu ieguvumus, mums ir jārisina atklātās problēmas, kas atklājās agrīnajā ieviešanā. Uzticamības jomā mēs redzam, ka koda asistenti pieļauj vairāk kļūdu nekā cilvēki, tāpēc pētījumiem jākoncentrējas uz kļūdu atklāšanu un stabilu ģenerēšanu. Plānošanas jomā mēs redzam, ka aģenti svārstās garos, daudzpakāpju projektos, tāpēc mums ir vajadzīgas jaunas arhitektūras un salīdzinošie kritēriji sarežģītām darba plūsmām. Pārbaudāmības jomā mēs atzīstam, ka mums ir nepieciešams formāls specifikācijas un testēšanas atbalsts, kas iebūvēts pašā AI kodēšanas procesā. Un pārvaldības jomā uzņēmumi un regulatori steidzas noteikt noteikumus, lai AI kods būtu caurskatāms, drošs un atbildīgs.

Nākamo 18 mēnešu laikā progress katrā no šīm jomām būs būtisks. Veidojot stingrus salīdzinošos kritērijus (no projektu plānošanas izaicinājumiem līdz AI izraisīto kļūdu pārbaudei), integrējot formālās metodes AI kodēšanas cauruļvados un veidojot sadarbību starp dažādām disciplīnām, mēs varam mazināt plaisu starp spilgtām demonstrācijām un reālas pasaules uzticamību. Vīzija ir skaidra: AI kodēšanas ekosistēma, kurā pat iesācēji var droši izveidot programmatūru, un kurā AI ģenerētais kods ir tikpat uzticams kā cilvēka radītais kods. Šīs vīzijas īstenošanai būs jāveido gan tehnoloģijas, gan tās apkārtējās prakses. Ar mērķtiecīgiem pētījumiem un plašiem kopienas centieniem nākamās paaudzes AI rīki patiesi var atklāt kodēšanu ikvienam – sākot jau šodien.