DHH apie AI agentų ribą: kodą jie rašo, bet ne visada jaučia, kada jo per daug

Kas nutinka programuotojui, kai AI jau gali ne tik pasiūlyti kelias kodo eilutes, bet ir naršyti projektą, keisti failus, vykdyti užduotis bei taisyti rezultatą po pastabų? „Ruby on Rails“ kūrėjo ir „37signals“ technologijų vadovo David Heinemeier Hansson, dažnai vadinamo DHH, patirtis su „Omarchy“ pateikia vieną galimą atsakymą: dalį kodo rašymo galima perduoti agentams, tačiau sprendimų vertinimas niekur nedingsta.

DHH pasakoja, kad dirbdamas prie naujesnės „Omarchy“ kartos pats kelis mėnesius neberašė Bash kodo naujam funkcionalumui. Tai nėra tas pats, kas teigti, jog visą ar beveik visą „Omarchy“ sukūrė AI agentai. Jo pasakojimas siauresnis – agentai perėmė didelę dalį konkretaus įgyvendinimo darbo, o jis pats liko atsakingas už kryptį, peržiūrą ir sprendimų paprastumą.

Būtent čia išryškėja DHH minima agentų silpnybė. Jie gali parašyti veikiantį kodą, tačiau ne visada gerai įvertina, ar pasirinktas sprendimas nėra neproporcingai sudėtingas pačiai problemai.

Agentas – jau nebe vien pažangesnis „autocomplete“

Tradicinis kodo papildymas laukia, kol žmogus pradės sakinį, ir pasiūlo jo tęsinį. Programavimo agentas veikia plačiau: gali perskaityti projekto failus, suprasti užduotį, pakeisti kelias sistemos dalis, paleisti komandas ar automatinius testus ir taisyti rezultatą pagal gautą grįžtamąjį ryšį.

„Omarchy“ atveju tokie agentai tapo realia kūrimo proceso dalimi. Pats DHH pasakoja, kad anksčiau, gavęs iš agento Bash sprendimą, dar stengdavosi jį perrašyti ar bent pats išsaugoti praktinį įgūdį. Vėliau, agentams gerokai patobulėjus, šio įpročio atsisakė.

Jo vertinimu, šiandien agentams dažnai pakanka kelių stiliaus taisyklių ir pastabų dėl sudėtingumo. Tai jo asmeninė darbo praktika konkrečiame projekte, o ne įrodymas, kad toks modelis vienodai tinka visoms komandoms ar visoms programinės įrangos rūšims.

Du agentai gali sutarti – ir vis tiek pasirinkti per sudėtingą kelią

Vienas iš DHH pateiktų pavyzdžių gerai parodo problemą. Agentas atlieka užduotį. Kitas agentas peržiūri jo darbą. Abu nusprendžia, kad rezultatas tinkamas.

Tada žmogus pasižiūri į sprendimą ir pasako: čia, regis, per daug sudėtingumo.

DHH teigimu, po tokios pastabos agentas neretai pats sutinka, kad sprendimą galima gerokai supaprastinti, ir sumažina jo apimtį. Problema ta, kad šios išvados jis ne visada prieina iš karto.

Tai parodo skirtumą tarp dviejų klausimų. Pirmasis – ar kodas veikia ir atitinka testus. Antrasis – ar problema išspręsta tinkamo masto mechanizmu.

Du sprendimai gali duoti tą patį rezultatą, nors vienas turi daugiau šakų, papildomų abstrakcijų, priklausomybių ar būsimų priežiūros taškų. Automatiniai testai gali patvirtinti funkcinį teisingumą, bet architektūrinio proporcingumo jie savaime negarantuoja.

DHH savo vaidmenį lygina su redaktoriumi

DHH savo dabartinį santykį su agentų kuriamu kodu lygina ne su žmogumi, kuris pats atlieka kiekvieną techninį veiksmą, o su kūrėju ar redaktoriumi, vertinančiu viso darbo formą.

Programinėje įrangoje tokios „proporcijos“ gali reikšti gebėjimą pastebėti, kad nedidelei problemai sukurtas pernelyg didelis mechanizmas, kad naujas komponentas dubliuoja jau egzistuojantį arba kad vietinis sprendimas nedera su likusia sistema.

Tam neužtenka vien mokėti parašyti gerą užklausą AI. Reikia suprasti pačią kodų bazę, jos architektūrą ir kompromisus. Kitaip sunku pastebėti, kad agento pasiūlymas, nors techniškai veikia, sistemai yra netinkamos formos.

DHH patirtis todėl nebūtinai rodo programuotojo profesijos „pabaigą“. Ji greičiau parodo vieną galimą darbo persiskirstymą patyrusio programuotojo rankose: mažiau mechaninio rašymo, daugiau vertinimo, atrankos ir koregavimo.

„Omarchy“ optimizavimas parodo, ką reiškia matyti visumą

Šis požiūris matomas ir pasakojant apie „Omarchy“ diegimo spartinimą. Viena optimizavimo kryptis buvo ne naujų funkcijų kūrimas, o nereikalingo svorio pašalinimas.

DHH pasakojo, kad ankstesnis sistemos atvaizdas siekė apie 7,5 GB, o naujesnę versiją pavyko sumažinti maždaug iki 5,85 GB. Didelė diegimo laiko dalis tenka suspaustų paketų išskleidimui, todėl mažesnis atvaizdas tiesiogiai trumpina dalį proceso.

Kai kurie laimėjimai atsirado iš labai smulkių sprendimų. Pavyzdžiui, standartinis „JetBrains“ šriftų paketas turėjo daug projekte nenaudojamų variantų. Palikus tik reikalingą monospace versiją, anot DHH, pavyko sutaupyti apie 180 MB. Dar apie 200 MB buvo sutaupyta agresyviau suspaudus du „Nvidia“ tvarkyklių paketus.

Tokie pavyzdžiai gerai iliustruoja jo argumentą apie proporcijas. Vertė nebūtinai slypi tame, kas parašė konkrečią eilutę. Ji gali būti gebėjimas pastebėti, kad tam tikro paketo dydis, veiksmų seka ar pasirinktas mechanizmas tiesiog neatitinka realaus poreikio.

Ką tokia patirtis gali reikšti programuotojui

Iš vieno projekto negalima daryti universalios išvados apie visą programuotojo profesiją. „Omarchy“ yra konkretus projektas, DHH – labai patyręs programuotojas, o skirtingose komandose agentų galimybės, rizikos ir priežiūros poreikis gali smarkiai skirtis.

Vis dėlto jo darbo būdas išryškina kelis įgūdžius, kurie tampa ypač svarbūs tada, kai pats kodo generavimas atpinga:

• suprasti visos sistemos, o ne vien vieno failo architektūrą;
• atskirti būtiną sudėtingumą nuo bereikalingo;
• suformuluoti, kokį rezultatą reikia pasiekti ir kokių ribų neperžengti;
• pastebėti sprendimus, kurie lokaliai veikia, bet blogina bendrą sistemos struktūrą;
• kritikuoti agento rezultatą net tada, kai techniniai patikrinimai klaidų nerodo.

Ar toks modelis taps dominuojančiu programuotojų darbo būdu, iš DHH patirties spręsti per anksti. Tačiau jo pavyzdys rodo aiškią ribą tarp kodo pagaminimo ir gero inžinerinio sprendimo.

AI agentai jau gali atlikti daug pirmojo darbo. Antrasis – nuspręsti, ar pasirinktas sprendimas nėra per didelis, per sudėtingas ar netinkamas visai sistemai – bent DHH darbo procese kol kas lieka žmogaus atsakomybė.