PDI Brew su DI agentais: darbuotojas parašo idėją, sistema pastato programėlę
·
DI agentai programėlėms š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ų?
DI agentai programėlėms PDI Brew istorijoje skamba beveik per paprastai: darbuotojas paprasta kalba aprašo, kokio įrankio reikia, o sistema sugeneruoja ir paleidžia daugianuomininkę web programėlę.
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
PDI Technologies su AWS sukūrė agentinę platformą, kur Amazon Bedrock padeda planuoti, o AWS Lambda provisioning agentas pasirūpina diegimu. Tikslas – kad vidiniai įrankiai atsirastų greičiau ir su daugiau valdymo.
Kiek įmonėse yra mažų įrankių, kurie niekada negimsta? Vienam reikia formos. Kitam lentelės. Trečiam mažo portalo. Visi laukia IT eilėje ir tyliai klijuoja procesą per Excel.
Č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
Agentinis app deployer rodo kryptį: DI gali ne tik pasiūlyti kodą, bet ir padėti sutvarkyti visą kelią nuo idėjos iki veikiančio vidinio įrankio.
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
Tai aktualu įmonėms, kuriose daug smulkių procesų, bet IT komanda užimta dideliais darbais. Svarbiausia čia ne greitis vienas pats, o valdymas.
- atskirti vidinius įrankius nuo klientų sistemų
- turėti šablonus ir taisykles
- riboti duomenų prieigą
- peržiūrėti sugeneruotą rezultatą prieš naudojimą
Geras kandidatas: vidinė užklausų registravimo programėlė, kuri šiandien gyvena el. pašte ir vienoje pavargusioje lentelėje.
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 – atidaryti duris šimtui neprižiūrimų įrankių. Jei nėra katalogo, savininko ir išjungimo taisyklių, greitis po kelių mėnesių tampa netvarka.
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ę suraskite vieną mažą vidinį įrankį, kurio komanda laukia seniai, ir aprašykite jį 10 sakinių paprasta kalba.
Šaltinis: AWS Machine Learning Blog.
DUK
Kas yra DI agentai programėlėms?
Tai agentinės sistemos, kurios iš aprašymo padeda suplanuoti, sukurti ir paleisti vidinį įrankį.
Ar tai pakeičia programuotojus?
Ne visur. Tai labiau nuima smulkių vidinių įrankių eilę, bet valdymas ir peržiūra lieka būtini.
Kur pradėti?
Nuo mažo, vidinio ir mažos rizikos proceso, kuriame aiški nauda ir duomenų ribos.
Jei nori DI naudoti praktiškai, pradėk nuo vieno proceso. Vienas pasikartojantis darbas. Vienas atsakingas žmogus. Vienas matavimas. Daugiau praktikos rasi MasterSprint.
