Dirbtinis intelektas kodą rašo puikiai – jei žinai, ko iš jo nori

Data: 2026 m. gegužės 28 d.

Kodėl „Claude Code“, Codex ir kiti DI kodavimo agentai geriausiai veikia ten, kur jau yra aiškūs inžineriniai procesai, DoR ir DoD.

Trumpai

DI kodavimo agentai, tokie kaip „Claude Code“ ir Codex, gali greitai vykdyti užduotis, bet neaiškius reikalavimus dažnai paverčia prielaidomis.

Komandos, jau taikančios „Agile“ praktikas, ypač Definition of Ready (DoR) ir Definition of Done (DoD), iš DI agentų gauna stabilesnius ir prognozuojamesnius rezultatus.

Šias sistemas galima integruoti tiesiai į DI darbo eigą: kaip užduoties patvirtinimo vartus prieš pradedant darbą ir kaip nuolat įkeliamus projekto kokybės reikalavimus.

Vienas dažniausiai kartojamų pažadų apie DI kodavimo įrankius skamba taip: jie pakeis programuotojus. Tikrovė, kaip įprasta, yra nuobodesnė ir įdomesnė tuo pat metu.

DI agentai nėra magiški. Jie greitai vykdo instrukcijas, bet ne visada sustoja paklausti, ar užduotis iš tiesų apibrėžta pakankamai aiškiai. Jei reikalavimai migloti, agentas vis tiek bandys dirbti. Ir būtent čia prasideda problema: jis dirba greitai, ryžtingai ir kartais klaidingai, nes niekas jam nepaaiškino, ko iš tiesų buvo norima.

Kada DI sustiprina chaosą

Dirbdamas su DI agentais, pastebėjau aiškų dėsningumą: komandos su tvirta inžinerine kultūra prie DI kodavimo įrankių pereina daug sklandžiau. Komandos be tokios kultūros susiduria su ta pačia problema, tik greičiau ir didesniu mastu.

Mano formuluotė paprasta: DI agentai sustiprina esamus procesus. Jei procesai tvirti, DI juos pagerina. Jei procesai chaotiški, DI chaosą padaro efektyvesnį – o to tikrai nenori.

Tai nėra nauja mintis apie technologijas. Elektrinis pjūklas taip pat nieko neklausia: jis tiesiog pjauna ten, kur nuvedi ranką. Skirtumas tas, kad su DI agentais greitis ir savarankiškumas yra daug didesni, o klaidų kaina gali augti kartu su mastu.

Senas sprendimas naujai problemai

„Agile“ metodologijoje jau seniai egzistuoja du įrankiai šiai problemai spręsti: Definition of Ready ir Definition of Done.

Paruoštumo apibrėžimas, arba Definition of Ready, yra kriterijų sąrašas, kurį užduotis turi atitikti prieš pradedant ją vykdyti. Klasikinis pavyzdys: komanda gauna užduotį „vartotojas nori matyti savo užsakymų istoriją“. Skamba paprastai. Tačiau be paruoštumo apibrėžimo niekas nenurodo, kas atsitinka, kai užsakymų paslaugos serveris grąžina klaidos kodą.

Ar rodyti klaidos pranešimą? Kartoti užklausą? Rodyti anksčiau išsaugotus duomenis? Trys skirtingi programuotojai gali duoti tris skirtingus atsakymus.

Atliktumo apibrėžimas, arba Definition of Done, sprendžia kitą pusę: ką reiškia, kad darbas baigtas? Istoriškai komandos vartojo posakį „baigta baigta“, pusiau juokais kalbėdamos apie tai, kad žodis „baigta“ ne visiems reiškia tą patį. Atliktumo apibrėžimas atsirado kaip atsakas į šį nesusipratimą.

Praktiškai tai gali atrodyti taip: kodas peržiūrėtas, vienetų testai parašyti ir veikia, naujų komponentų kodo aprėptis siekia bent 80%, pasiekti sutarti našumo rodikliai, tenkinami WCAG 2.1 AA prieinamumo reikalavimai, dokumentacija atnaujinta, kodas perkeltas į testavimo aplinką.

Jei naudojami Core Web Vitals kriterijai, verta juos įvardyti tiksliai: pavyzdžiui, LCP turėtų įvykti per 2,5 sekundės nuo puslapio įkėlimo pradžios, o ne abstrakčiai vadintis „naršymo sparta“. Google Core Web Vitals taip pat apima INP ir CLS rodiklius.

Kaip tai veikia su DI agentais

Siūlau du praktinius būdus, kaip šias sistemas pritaikyti DI darbo eigoms.

Pirma priemonė – paruoštumo apibrėžimas kaip užduoties patvirtinimo vartai. Prieš duodant užduotį DI agentui, reikia pereiti kontrolinį klausimų sąrašą.

Ar apibrėžti klaidų tvarkymo scenarijai? Ar nurodytos priklausomybės? Ar aiškus laukiamas rezultatas? Ar aprašyti kraštutiniai atvejai? Jei atsakymas į bet kurį iš šių klausimų yra „ne“, DI agentas dar negavo pakankamai informacijos.

Antra priemonė – projekto lygio instrukcijų failai. „Claude Code“ atveju tai yra CLAUDE.md failas: Markdown dokumentas, kurį agentas naudoja kaip projekto kontekstą. Į jį galima įrašyti projekto kokybės reikalavimus: kokias testavimo sistemas naudoti, kokius linting taisyklių rinkinius taikyti, kokios kodo aprėpties tikėtis, kokie saugumo ar architektūros principai galioja projekte.

Codex atveju panašų vaidmenį atlieka AGENTS.md ir Codex Rules mechanizmas. Taisyklės leidžia apibrėžti nuolatines instrukcijas, kurių nereikia kartoti kiekvienoje užduotyje.

Tai reiškia, kad atliktumo apibrėžimas gali iš komandos susitarimo tapti nuolat įkeliamu projekto kontekstu. Jis nepakeičia žmogaus peržiūros, bet sumažina priklausomybę nuo atminties, improvizacijos ir nevienodų standartų.

Lietuvos kontekstas: inžinerinė kultūra kaip konkurencinis pranašumas

Lietuva turi ryškią technologijų ekosistemą: nuo „Vinted“ iki fintech sektoriaus. Tačiau DI įrankių diegimas be struktūruotų procesų yra praktinė, o ne teorinė rizika.

Komandos, neturinčios aiškių inžinerinių standartų, susidurs su paradoksu: DI įrankiai leis daryti daugiau ir greičiau, bet kartu leis greičiau dauginti klaidas. Startuoliai, kurie pirma investuos į procesų kultūrą ir tik po to į DI agentus, turės struktūrinį pranašumą prieš tuos, kurie elgsis atvirkščiai.

Mano tezė paprasta: DI nėra magija, pakeičianti tvarkingą darbą. Tai stiprintuvas. Todėl svarbu ne tik tai, kad stiprini, bet ir ką stiprini – gerą signalą ar triukšmą.

Kas liks žmogaus rankose

Šis požiūris kelia subtilų, bet svarbų klausimą. Jei DI agentas veikia pagal aiškiai suformuluotus reikalavimus, o jo darbas vertinamas pagal aiškius kriterijus, kur lieka inžinierių kūrybiškumas ir sprendimų priėmimas?

Atsakymas, bent jau šiame etape, yra toks: reikalavimai vis tiek turi ateiti iš žmogaus.

Paruoštumo apibrėžimas negali parašyti pats savęs. Kažkas turi nuspręsti, kad 80% kodo aprėptis yra priimtinas slenkstis, o ne 70% ar 95%. Kažkas turi nuspręsti, kokie prieinamumo standartai svarbūs konkrečiam produktui. WCAG 2.1 apibrėžia, kaip skaitmeninį turinį padaryti prieinamesnį žmonėms su įvairiomis negaliomis, tačiau konkrečios komandos vis tiek turi nuspręsti, kaip tuos reikalavimus taikyti savo produktui.

DI išlaisvina inžinierius nuo dalies mechaninio darbo. Tačiau strateginių sprendimų atsakomybės iš jų kol kas neatima.

Ponas Obuolys sako

Technologijų pasaulis turi ilgą tradiciją pardavinėti tuos pačius principus kiekvienai naujai kartai, tik vis kitaip supakuotus. „Agile“ atėjo išgelbėti mus nuo vandens krioklio metodologijos. „DevOps“ – išgelbėti nuo „Agile“ biurokratijos. Dabar DI agentai žada išgelbėti mus nuo paties programavimo.

Ir štai kas ironiška: geriausia strategija dirbant su DI agentais iš esmės yra ta pati, kuri visada buvo gera strategija dirbant su žmonėmis.

Paaiškink, ko nori. Apibrėžk, kaip atrodys sėkmė. Patikrink rezultatą.

Skirtumas tas, kad DI agentas nepavargsta žmogaus prasme ir netampa pasyviai agresyvus po ketvirto klausimo „bet ar tikrai būtina rašyti tuos testus?“. Tačiau jis taip pat ne visada supras, kad reikalavimai buvo neaiškūs, kol nebus per vėlu.

Todėl CLAUDE.md, AGENTS.mdar bet kuris kitas projekto instrukcijų failas yra ne tik techninis sprendimas. Tai laiškas kolegai, kuris yra labai stropus, labai greitas ir visiškai priklausomas nuo to, ar sugebėjai aiškiai aprašyti kontekstą.

Šaltiniai / idėjinis pagrindas: Anthropic „Claude Code“ dokumentacija; Codex dokumentacija; Google Core Web Vitals; W3C WCAG.