Dauguma programinės įrangos kūrėjų, techninių vadovų ir DevOps inžinierių karjerą pradeda kaip kūrėjai.

Jie kuria sistemas, programas, komponentus, temas, šablonus, modulius ir procesų grandines. Optimizuoja maketus, taiso kraštutinius atvejus, rūpinasi suderinamumu ir stumia sistemas pirmyn po vieną įrašą (commit). Darbas tikslus, praktiškas ir labai techniškas.

Bet vienu metu kai kas pasikeičia.

Geriausi specialistai nustoja kurti ne todėl, o todėl, kad pradeda mąstyti sistemomis.

Nuo kūrėjo iki sistemų mąstytojo

Poslinkis: nuo rezultato prie taisyklių

Kūrėjui svarbiausias yra rezultatas: komponentai, šablonai, puslapiai, funkcijos, bibliotekos, programos.

Sistemų mąstytojui dėmesys krypsta į taisykles: apribojimus, sąveikas, grįžtamojo ryšio kilpas.

Užuot klausę „Kaip atrodo šis komponentas?“, sistemų mąstytojai klausia kitaip: Kokios taisyklės jį valdo? Kam leidžiama su juo sąveikauti? Kaip jis elgiasi keičiantis aplinkybėms? Kaip sumanymas išlieka bėgant laikui?

Šis poslinkis natūraliai veda link agentinių sistemų.

Kai dizainas nustoja būti statiškas

Šiuolaikinės dizaino sistemos jau koduoja logiką: ženklai (tokens) apibrėžia apribojimus, komponentai – struktūrą, šablonai – elgseną.

Vis dėlto dauguma sistemų vis dar remiasi sunkia žmogaus vykdoma orkestracija.

DI agentai atneša kitokį modelį, kuriame sistemos gali pačios vykdyti savo taisykles, nuolat tikrinti sprendimus, reaguoti į kontekstą ir koordinuotis viduje.

Čia dizainas iš dokumentacijos virsta vykdoma logika.

Kur tai link veda

Dabar svarbiausia šias idėjas įgyvendinti tikrose, veikiančiose sistemose – ne kaip eksperimentus, o kaip pamatus.

1. Gilesnė DI agentų integracija su dizaino įrankiais (Figma)

Link agentinių dizaino sistemų

Dizaino įrankiai neturėtų būti pasyvūs drobės lapai.

Tikslas – integruoti su Figma DI agentus, kurie supranta dizaino ženklus ir komponentų apribojimus, realiuoju laiku tikrina sprendimus, paverčia dizaino sumanymą sistemos lygio taisyklėmis ir veikia kaip bendradarbiai, o ne eksportuotojai.

Taip dizainas perkeliamas į pradžią, kur sumanymas išsaugomas, o ne vėliau atspėjamas.

2. Keičiamo mastelio DI agentų valdymas

Tikslas: 150 agentų – po vieną kiekvienam komponentui

Užuot pasikliovusios vienu universaliu DI, komandos pereina prie daugybės specializuotų agentų.

Kiekvienas komponentas gauna savo agentą su apibrėžtomis atsakomybėmis, aiškiomis ribomis ir žiniomis apie susijusius komponentus.

Taip auga ir sveikos sistemos: per specializaciją, koordinavimą ir aiškias sutartis.

3. Agentai su tikrais įgūdžiais, įrankiais ir papildiniais

Agentai turi sugebėti veikti.

Tai reiškia aprūpinti juos įgūdžiais (prieinamumo vertinimas, dizaino patikra, supratimas apie našumą), įrankiais (kodo analizatoriais, testų vykdytuvais, dizaino API) ir papildiniais (Storybook, Drupal, CI procesų grandinės, Figma integracijos).

Agentas be įrankių tėra teorija. Agentas su įrankiais tampa pačios sistemos dalimi.

4. Išmanesnis automatizuotas funkcinis priėmimo testavimas

DI valdomas ir sumanymą suprantantis

Tradicinis testavimas tikrina rezultatą. Agentų valdomas testavimas supranta elgseną.

Dėmesys skiriamas DI agentams, kurie samprotauja apie naudotojo kelionės žingsnius, funkciniams testams, kurie supranta sumanymą, o ne tik selektorius, sistemoms, kurios testus plėtoja kartu su komponentais, ir trapių testų mažinimui kartu didinant semantinį pasitikėjimą.

Testavimas tampa dar vienu sistemos intelekto sluoksniu.

TDD ir BDD DI amžiuje: kodėl DI agentai reikalauja 100 % daugiau testais grįsto kūrimo

Kodėl tai svarbu

Komandos kuria sistemas, kurios išgyvena savo kūrėjus, nuolat prisitaiko ir neša ilgalaikius dizaino sprendimus į ateitį.

Tokiame pasaulyje rankinė kontrolė nebeauga kartu su sistema. O gerai apibrėžtos taisyklės auga.

Dizaineriai, kūrėjai ir DI agentai turi veikti toje pačioje loginėje sistemoje – vienoje bendroje apribojimų ir sumanymo visumoje.

Perėjimas nuo kūrėjo prie sistemų mąstytojo nereiškia atsisakyti įgyvendinimo. Jis reiškia matyti sistemas kaip daugiau nei dalių rinkinį.

Kitas žingsnis – kurti taisykles, leidžiančias sistemoms samprotauti, prisitaikyti ir vystytis.

Programinės įrangos kūrėjai, techniniai vadovai ir DevOps inžinieriai, žengiantys šį žingsnį, ne šiaip kuria – jie kuria sąlygas, kad sistemos kurtų pačios save.