Lielākā daļa programmatūras izstrādātāju, tehnisko vadītāju un DevOps inženieru karjeru sāk kā būvētāji.

Viņi būvē sistēmas, lietotnes, komponentes, tēmas, paraugus, moduļus un konveijerus. Viņi pilnveido izkārtojumus, labo robežgadījumus, uztur saderību un virza sistēmas uz priekšu pa vienam komitam. Darbs ir precīzs, praktisks un dziļi tehnisks.

Taču kādā brīdī kaut kas mainās.

Labākie profesionāļi nepārstāj būvēt, bet sāk domāt sistēmās.

No būvētāja par sistēmu domātāju

Pārmaiņa: no rezultāta pie noteikumiem

Būvētājam uzmanības centrā ir rezultāts: komponentes, sagataves, lapas, funkcijas, bibliotēkas, lietojumprogrammas.

Sistēmu domātājam fokuss pārvietojas uz noteikumiem: ierobežojumiem, mijiedarbību, atgriezeniskās saites cilpām.

Tā vietā, lai jautātu: "Kā šī komponente izskatās?", sistēmu domātāji uzdod citus jautājumus: kādi noteikumi šo komponenti regulē? Kam ir atļauts ar to mijiedarboties? Kā tā uzvedas pārmaiņu apstākļos? Kā nodoms saglabājas laika gaitā?

Šī pārmaiņa dabiski ved uz aģentiskām sistēmām.

Kad dizains vairs nav statisks

Mūsdienu dizaina sistēmas jau kodē loģiku: tokeni nosaka ierobežojumus, komponentes nosaka struktūru, paraugi nosaka uzvedību.

Tomēr lielākā daļa sistēmu joprojām ir atkarīgas no apjomīgas cilvēku veiktas koordinēšanas.

MI aģenti ievieš citu modeli, kurā sistēmas var pašas īstenot savus noteikumus, nepārtraukti pārbaudīt lēmumus, reaģēt uz kontekstu un koordinēties iekšēji.

Tieši šeit dizains no dokumentācijas attīstās par izpildāmu loģiku.

Kurp tas virzās

Tagad uzmanība ir pievērsta šo ideju īstenošanai reālās, strādājošās sistēmās, nevis kā eksperimentiem, bet kā pamatiem.

1. Dziļāka MI aģentu integrācija ar dizaina rīkiem (Figma)

Ceļā uz aģentiskām dizaina sistēmām

Dizaina rīkiem nevajadzētu būt pasīviem audekliem.

Mērķis ir integrēt Figma ar MI aģentiem, kas izprot dizaina tokenus un komponenšu ierobežojumus, reāllaikā pārbauda lēmumus, pārvērš dizaina nodomu sistēmas līmeņa noteikumos un darbojas kā līdzstrādnieki, nevis kā eksportētāji.

Tas dizainu pārceļ uz agrāku posmu, kur nodoms tiek saglabāts, nevis vēlāk minēts.

2. Mērogojama MI aģentu pārvaldība

Mērķis: 150 aģentu, katrai komponentei savs

Tā vietā, lai izmantotu vienu vispārējas nozīmes MI, komandas virzās uz daudziem specializētiem aģentiem.

Katra komponente saņem savu aģentu ar definētiem pienākumiem, skaidrām robežām un izpratni par saistītajām komponentēm.

Tā mērogojas veselīgas sistēmas: ar specializāciju, koordināciju un skaidriem līgumiem.

3. Aģenti ar īstām prasmēm, rīkiem un spraudņiem

Aģentiem jāspēj rīkoties.

Tas nozīmē tos apgādāt ar prasmēm (piekļūstamības izpratne, dizaina validācija, veiktspējas apzināšanās), rīkiem (linteri, testu izpildītāji, dizaina API) un spraudņiem (Storybook, Drupal, CI konveijeri, Figma integrācijas).

Aģents bez rīkiem ir teorētisks. Aģents ar rīkiem kļūst par pašas sistēmas daļu.

4. Gudrāka automatizētā funkcionālās akceptēšanas testēšana

MI vadīta un nodomu izprotoša

Tradicionālā testēšana pārbauda rezultātu. Aģentu vadīta testēšana izprot uzvedību.

Uzmanības centrā ir MI aģenti, kas spriež par lietotāju ceļiem, funkcionālie testi, kas izprot nodomu, nevis tikai selektorus, sistēmas, kas attīsta testus līdzi komponentēm, un trauslu testu samazināšana, vienlaikus palielinot semantisko pārliecību.

Testēšana kļūst par vēl vienu sistēmas intelekta slāni.

TDD un BDD MI laikmetā: kāpēc MI aģenti prasa par 100% vairāk izstrādes ar testiem pirmajā vietā

Kāpēc tas ir svarīgi

Komandas būvē sistēmas, kas pārdzīvo savus radītājus, nepārtraukti pielāgojas un nes līdzi ilgtermiņa dizaina lēmumus.

Šādā pasaulē manuāla kontrole nemērogojas. Bet labi definēti noteikumi mērogojas.

Dizaineriem, izstrādātājiem un MI aģentiem jādarbojas vienā loģiskā ietvarā, vienotā ierobežojumu un nodomu sistēmā.

Pāreja no būvētāja uz sistēmu domātāju nenozīmē atteikties no īstenošanas. Tā nozīmē redzēt sistēmas kā ko vairāk nekā detaļu kopumu.

Nākamais solis ir izstrādāt noteikumus, kas ļauj sistēmām spriest, pielāgoties un attīstīties.

Programmatūras izstrādātāji, tehniskie vadītāji un DevOps inženieri, kas veic šo pāreju, nevis tikai būvē, bet rada apstākļus, kuros sistēmas var pašas sevi būvēt.