Conductor ir Antigravity: specifikacijos grįžta į agentų kūrimą
·
spec-driven development šiandien nėra tik dar vienas techninis žodis. Tai klausimas, ar DI jau padeda atlikti tikrą darbą, ar tik gražiai atrodo prezentacijoje.
Google Developers liepos 16 d. paskelbė, kad Conductor dabar palaiko Antigravity. Po gražiu pavadinimu slepiasi sena, bet labai reikalinga mintis: prieš leidžiant agentui kurti, reikia aiškiai susitarti, ką jis kuria.
Ir čia man visada įsijungia tas vidinis balsas: gerai, o kas realiai pasikeis pirmadienį ryte? Ne laboratorijoje. Ne konferencijoje. Normalioje komandoje, kur yra darbai, sąskaitos, klientai ir ribotas laikas.
KAS NUTIKO
Spec-driven development agentų kontekste reiškia, kad užduotis aprašoma kaip specifikacija, o ne kaip miglotas noras. Agentas turi daugiau aiškumo: kokios funkcijos reikia, kokie apribojimai galioja, kaip tikrinsime rezultatą.
Čia kaip statybose. Jei pasakai „padaryk gražų kambarį“, gausi fantaziją. Jei pasakai matmenis, paskirtį, elektros taškus ir biudžetą, jau galima dirbti. DI agentams tas pats.
KODĖL TAI SVARBU
Kuo agentai tampa savarankiškesni, tuo brangiau kainuoja neaiškios užduotys. Agentas gali padaryti daug darbo. Bet jei jis daro ne tą darbą, gauname greitą klaidų fabrikėlį.
DI rinka po truputį keliasi iš „pažiūrėk, ką sugeneravo“ į „pažiūrėk, ką patikimai padarė“. Skirtumas didelis. Viena yra demonstracija. Kita – procesas, kurį galima kartoti ir prižiūrėti.
KĄ TAI REIŠKIA VERSLUI
Verslui tai svarbu ne tik programuojant. Specifikacijos gali būti naudingos kuriant ataskaitas, procesų automatiką, klientų aptarnavimo scenarijus ar vidinius įrankius.
- aprašyti rezultatą prieš paleidžiant agentą
- nurodyti ribas ir draudžiamus veiksmus
- turėti priėmimo kriterijus
- saugoti specifikacijas kaip procesų dokumentaciją
Jei agentas kuria vidinę ataskaitą, specifikacijoje turi būti aišku: kam ji skirta, kokie duomenys naudojami, koks formatas, kas yra klaida ir kas turi patvirtinti.
KUR PASISLĖPUSI RIZIKA
Rizika – manyti, kad agentas pats supras verslo kontekstą. Kartais supras. Kartais labai pasitikinčiai prašaus pro šalį.
Blogiausia DI klaida dažnai ateina ne su triukšmu. Ji ateina tvarkingu sakiniu, mandagiu tonu ir labai užtikrintu veidu. Todėl patikra nėra biurokratija. Tai darbo higiena.
KĄ PASIDARYTI ŠIĄ SAVAITĘ
Prieš kitą agento užduotį parašykite penkis sakinius: tikslas, įvestis, rezultatas, ribos, patikra. Tai jau mažas specifikacijos stuburas.
Šaltinis: Google Developers.
DUK
Kas yra spec-driven development?
Tai kūrimo būdas, kai pirmiausia aiškiai aprašomas norimas rezultatas ir tik tada pradedama įgyvendinti.
Kodėl tai tinka DI agentams?
Nes agentams reikia aiškių ribų, kad jie nešvaistytų darbo neteisinga kryptimi.
Ar tai tik programuotojams?
Ne. Specifikacijos padeda bet kuriame procese, kuriame DI turi atlikti aiškų darbą.
Jei norite DI naudoti praktiškai, pradėkite nuo vieno proceso. Ne nuo įrankių sąrašo. Ne nuo madingo modelio. Paimkite darbą, kuris kartojasi, išmatuokite rezultatą ir tik tada junkite DI. Daugiau praktinių pavyzdžių rasite MasterSprint.
