Enamik tarkvaraarendajaid, tehnikajuhte ja DevOps-insenere alustab oma karjääri ehitajatena.

Nad ehitavad süsteeme, rakendusi, komponente, teemasid, mustreid, mooduleid ja torujuhtmeid. Nad optimeerivad paigutusi, lahendavad äärejuhtumeid, hoiavad ühilduvust ja viivad süsteeme edasi ühe commit'i kaupa. Töö on täpne, praktiline ja sügavalt tehniline.

Kuid ühel hetkel nihkub midagi.

Parimad praktikud ei lakka ehitamast, kuid nad hakkavad mõtlema süsteemide kaudu.

Ehitajast süsteemimõtlejaks

Nihe: väljundilt reeglitele

Ehitajana on fookuses väljund: komponendid, mallid, lehed, funktsioonid, teegid, rakendused.

Süsteemimõtlejana nihkub fookus reeglitele: piirangutele, vastasmõjudele, tagasisideahelatele.

Selle asemel et küsida „Kuidas see komponent välja näeb?“, küsivad süsteemimõtlejad teistsuguseid küsimusi: millised reeglid seda komponenti juhivad? Mis tohib sellega suhelda? Kuidas see muutuste all käitub? Kuidas jääb algne kavatsus aja jooksul püsima?

See nihe viib loomulikult agentsete süsteemideni.

Kui disain lakkab olemast staatiline

Kaasaegsed disainisüsteemid kodeerivad juba loogikat: tokenid määravad piirangud, komponendid struktuuri, mustrid käitumise.

Ometi toetub enamik süsteeme endiselt suurele inimlikule orkestreerimisele.

Tehisintellekti agendid toovad kaasa teistsuguse mudeli, kus süsteemid suudavad ise oma reegleid jõustada, otsuseid pidevalt kontrollida, kontekstile reageerida ja seespidiselt koordineerida.

Siin areneb disain dokumentatsioonist täidetavaks loogikaks.

Kuhu see liigub

Nüüd on fookus nende ideede rakendamisel päris, töötavates süsteemides, mitte katsetustena, vaid vundamendina.

1. Sügavam tehisintellekti agentide lõimimine disainitööriistadega (Figma)

Agentsete disainisüsteemide suunas

Disainitööriistad ei tohiks olla passiivsed lõuendid.

Eesmärk on lõimida Figmaga tehisintellekti agendid, mis mõistavad disainitokeneid ja komponentide piiranguid, kontrollivad otsuseid reaalajas, tõlgivad disainikavatsuse süsteemitaseme reegliteks ja tegutsevad kaastöötajatena, mitte eksportijatena.

See viib disaini ülesvoolu, kus kavatsus säilib, mitte ei tuleta seda hiljem ära arvata.

2. Skaleeritav tehisintellekti agentide haldus

Siht: 150 agenti, üks komponendi kohta

Ühe üldotstarbelise tehisintellekti asemel liiguvad meeskonnad paljude spetsialiseeritud agentide suunas.

Iga komponent saab oma agendi, kellel on määratletud vastutus, selged piirid ja teadlikkus seotud komponentidest.

See kordab seda, kuidas terved süsteemid skaleeruvad: spetsialiseerumise, koordineerimise ja selgete lepete kaudu.

3. Päris oskuste, tööriistade ja pistikprogrammidega agendid

Agendid peavad suutma tegutseda.

See tähendab nende varustamist oskustega (ligipääsetavuse analüüs, disaini valideerimine, jõudlustaju), tööriistadega (linterid, testijooksutajad, disaini API-d) ja pistikprogrammidega (Storybook, Drupal, CI-torujuhtmed, Figma lõimingud).

Agent ilma tööriistadeta on teoreetiline. Tööriistadega agent muutub süsteemi enda osaks.

4. Nutikam automatiseeritud funktsionaalne vastuvõtutestimine

Tehisintellektil põhinev ja kavatsust arvestav

Traditsiooniline testimine kontrollib väljundit. Agendipõhine testimine mõistab käitumist.

Fookuses on tehisintellekti agendid, kes arutlevad kasutajateekondade üle, funktsionaalsed testid, mis mõistavad kavatsust, mitte ainult selektoreid, süsteemid, mis arendavad teste koos komponentidega, ning habraste testide vähendamine koos semantilise kindluse suurendamisega.

Testimisest saab veel üks süsteemiintelligentsi kiht.

TDD ja BDD tehisintellekti ajastul: miks tehisintellekti agendid nõuavad 100% rohkem testidest lähtuvat arendust

Miks see oluline on

Meeskonnad ehitavad süsteeme, mis elavad oma loojad üle, kohanduvad pidevalt ja kannavad pikaajalisi disainiotsuseid edasi.

Sellises maailmas käsitsi kontroll ei skaleeru. Küll aga skaleeruvad hästi defineeritud reeglid.

Disainerid, arendajad ja tehisintellekti agendid peavad tegutsema ühe loogilise raamistiku sees, ühtse piirangute ja kavatsuste süsteemi sees.

Üleminek ehitajast süsteemimõtlejaks ei tähenda teostusest loobumist. See tähendab süsteemide nägemist millegi enamana kui osade kogumina.

Järgmine samm on kujundada reegleid, mis lasevad süsteemidel arutleda, kohaneda ja areneda.

Tarkvaraarendajad, tehnikajuhid ja DevOps-insenerid, kes selle nihke teevad, ei ehita enam pelgalt, nad ehitavad tingimusi, mille toel süsteemid ehitavad end ise.