monday.com DI agentai: produkcija prasideda nuo senos kodo bazės
·

monday.com DI agentai šiandien skamba kaip dar viena DI naujiena. Bet aš į tai žiūriu paprasčiau: ar nuo to rytoj žmogui darbe bus aiškiau, greičiau arba saugiau?
AWS aprašė, kaip monday.com leidžia DI agentus produkcijoje su Amazon Bedrock. Įdomiausia čia ne blizgus demo, o labai žemiškas faktas: agentai turi dirbti dešimtmetį augusioje kodo bazėje.
Atvirai? Naujienų sraute lengva apsvaigti nuo pavadinimų. Vieną dieną naujas modelis, kitą dieną agentas, trečią – dar vienas įrankis. Todėl verta klausti ne „kas čia gražu?“, o „kur čia darbas?“
KAS NUTIKO
monday.com pasakoja apie AI Teammates, kurie padeda inžinerinėms komandoms dirbti su kodu ir procesais. AWS tekste minimi vidiniai duomenys: 9 iš 10 kūrėjų kas mėnesį naudoja DI kodavimo įrankius, o PR našumas vienam inžinieriui išaugo daugiau nei per pusę.
Čia ne laboratorija su švariu repo ir viena gražia užduotimi. Čia realus verslas: senas kodas, daug komandų, daug priklausomybių ir žmonės, kurie nenori, kad agentas penktadienį sugadintų pirmadienį.
KODĖL TAI SVARBU
monday.com DI agentai svarbūs todėl, kad parodo perėjimą nuo pavienių asistentų prie komandinių darbo draugų. Agentas ne tik parašo kodą. Jis turi suprasti kontekstą, patikrinti pasitikėjimą ir įsikomponuoti į esamą procesą.
DI iš tekstų dėžutės jau persikėlė į procesus. Jis jungiasi prie dokumentų, sistemų, balso, kodo, mokymų ir klientų užklausų. Ten prasideda ne magija, o labai žemiška vadyba.
KĄ TAI REIŠKIA VERSLUI
Verslui čia labai aiški pamoka: DI diegimas neprasideda nuo idealaus proceso. Jis dažnai prasideda nuo netvarkingos realybės. Laimi tie, kurie geba po truputį įdėti kontrolę, matavimą ir atsakomybę.
- rinkti vidinius naudojimo duomenis
- matuoti rezultatą vienam žmogui, ne tik bendrą aktyvumą
- pradėti nuo darbo, kur agentas padeda komandai
- nepaleisti automatinio merge be pasitikėjimo vertinimo
Pirmas žingsnis gali būti agentas, kuris paruošia PR santrauką ir rizikos vietas. Sprendimą vis tiek priima žmogus.
KUR GALIMA PASLYSTI
Rizika – įsimylėti našumo skaičių ir pamiršti kokybę. Daugiau PR nereiškia geriau, jei po to daugiau laiko suvalgoma taisymams.
Dažniausia klaida čia paprasta: paleisti įrankį greičiau, nei susitarti dėl ribų. Kas tikrina? Kas atsako? Kada stabdome? Be šitų klausimų DI tampa dar viena sistema, kurią kažkas pavargęs prižiūri penktadienio vakarą.
KĄ PASIDARYTI ŠIĄ SAVAITĘ
Peržiūrėkite vieną kūrėjų ar operacijų procesą ir nuspręskite, kur agentas turėtų ruošti darbą, o kur žmogus turi tvirtinti.
Šaltinis: Amazon Web Services.
DUK
Ką parodė monday.com?
Kaip DI agentai veikia produkcinėje inžinerijos aplinkoje su Amazon Bedrock.
Kokius skaičius mini AWS?
9 iš 10 kūrėjų naudoja DI kodavimo įrankius kas mėnesį, o PR našumas išaugo daugiau nei per pusę.
Kokia pamoka verslui?
Agentus reikia matuoti pagal rezultatą, kokybę ir riziką, ne vien pagal naudojimą.
Jei norite DI taikyti praktiškai, pradėkite nuo vieno darbo. Ne nuo visos įmonės perstatymo. Vienas procesas, viena atsakomybė, vienas matas. Daugiau praktinių DI taikymo pavyzdžių rasite MasterSprint.


