monday.com DI komandos draugai: agentai jau matuojami pull requestais

·


monday.com DI agentų architektūra Amazon Bedrock aplinkoje

DI komandos draugai šiandien nėra teorinis žaislas. Tai jau darbas, pinigai, duomenys ir kartais labai žemiškas klausimas: kas prisiims atsakomybę, kai DI pradės veikti už žmogų?

AWS liepos 22 d. paskelbė monday.com istoriją apie AI Teammates – produkcijoje veikiančius DI agentus, pastatytus ant Amazon Bedrock. Ten jau kalbama ne apie žaislą, o apie realius kūrėjų darbo skaičius.

Turiu prisipažinti, tokias naujienas skaitau ne kaip blizgančią vitriną. Skaitau kaip žmogus, kuris iš karto galvoja apie komandą pirmadienio rytą. Kas iš to bus naudinga? Kur bus painiava? Ir kur po mėnesio kas nors pasakys: „mes galvojom, kad čia automatiškai susitvarkys“.

KAS NUTIKO

monday.com aprašo agentų architektūrą, senos kodo bazės pritaikymą, pasitikėjimo balus ir pull request darbo eigą. Publikacijoje minima, kad devyni iš dešimties kūrėjų naudoja DI kodavimo įrankius kas mėnesį, o PR pralaidumas išaugo daugiau nei per pusę.

Kai skaitau tokius pavyzdžius, man norisi ne ploti, o klausti: o kaip jie tai suvaldė? Nes greitį nusipirkti lengviau nei discipliną.

Čia svarbi detalė: kalbame ne apie dar vieną gražų demonstracinį video. Kalbame apie produktus, politiką, infrastruktūrą arba tyrimus, kurie keičia, kaip žmonės dirba su DI realiose organizacijose.

KODĖL TAI SVARBU

DI agentas programuotojų komandoje veikia tik tada, kai yra aiškūs darbų vienetai, testai, peržiūra ir atsakomybė. Be to jis tampa dar vienu triukšmo šaltiniu.

DI jau išlipo iš „parašyk tekstą“ dėžutės. Jis naršo, jungiasi prie įrankių, analizuoja duomenis, planuoja veiksmus, kartais tvarko dokumentus ar padeda priimti sprendimą. Trumpai: jis artėja prie darbo proceso, ne tik prie pokalbio lango.

Ir čia smegenys mėgsta paslysti. Norisi sakyti: „ai, čia dar užsienyje“. Bet tas pats modelis ar funkcija rytoj atsiras kliento kompiuteryje, darbuotojo naršyklėje arba partnerio pasiūlyme.

KĄ TAI REIŠKIA VERSLUI

Verslui tai labai praktiškas signalas. Agentai pradeda keisti ne darbuotojus, o darbo eigas. Ypač ten, kur yra pasikartojantys pataisymai, techninė skola, testai ir dokumentacija.

  • skaičiuoti užbaigtas užduotis, ne sugeneruotas eilutes
  • naudoti pasitikėjimo balus
  • laikyti žmogaus peržiūrą kaip vartus
  • mokyti komandą rašyti geras užduotis agentui

Pirmas pilotas gali būti mažų pataisų eilė: aiškus ticketas, testas, agento PR ir žmogaus peržiūra. Jokių herojiškų pertvarkymų pirmą dieną.

Man patinka paprastas testas: ar po šios naujienos tavo komanda turi vieną aiškesnį sprendimą? Jei ne, vadinasi dar tik skaitome. Skaityti galima. Tik nereikia apsimesti, kad tai jau strategija.

KUR GALI SKAUDĖTI

Rizika – agentus diegti kaip motyvacinį plakatą. Jei nematuojate, kiek užduočių realiai užsidaro, turite nuotaiką, ne sistemą.

Dažniausia klaida labai ūkiška. Žmonės įsijungia įrankį, pabando, nustemba, pasidžiaugia ir tada palieka viską savieigai. Po kelių savaičių paaiškėja, kad vieni darbuotojai kelia jautrius failus, kiti matuoja naudą iš jausmo, o treti net nežino, kas leidžiama.

Ne tragedija. Bet tvarkos reikia.

KĄ PASIDARYTI ŠIĄ SAVAITĘ

Šią savaitę pasirinkite vieną kodo darbų tipą, kurį agentas gali ruošti, bet ne pats galutinai patvirtinti.

Šaltinis: Amazon Web Services.

DUK

Kas yra DI komandos draugai?

Tai agentai, kurie padeda komandai atlikti konkrečius darbus, pavyzdžiui, kurti kodo pakeitimus ar ruošti testus.

Kaip matuoti jų naudą?

Per užbaigtas užduotis, klaidų skaičių, peržiūros laiką ir poveikį komandos darbo eigai.

Ar agentas gali pats keisti produkciją?

Brandžioje komandoje tokie pakeitimai turi eiti per peržiūrą, testus ir aiškius vartus.

Jei nori DI naudoti praktiškai, pradėk nuo vieno proceso. Vienas pasikartojantis darbas. Vienas atsakingas žmogus. Vienas matavimas. Daugiau praktikos rasi MasterSprint.