Դիզայնը կոդն է

Ինչպես են բջջային ավտոմատների տրամաբանությունը վերաձևելու ագենտային դիզայն-համակարգերը, և ինչու վեբ-մշակման ապագան գուցե արդեն գրված է պարզ կանոններով

Դիզայն-համակարգերի, արհեստական բանականության և հաշվողական տեսության հատման կետում խորը փոփոխություն է տեղի ունենում։ Այն այնքան հիմնարար է, որ վիճարկում է այն պատկերացումը, թե ինչ է նշանակում «դիզայն» ինքնավար ագենտների դարաշրջանում։

Տասնամյակներ շարունակ դիզայնն ու կոդը դիտարկել ենք որպես առանձին ոլորտներ. դիզայնը՝ մարդու ստեղծագործության և գեղագիտական դատողության տարածք, կոդը՝ այդ գաղափարների մեխանիկական թարգմանություն կատարվող տեսքի։ Բայց երբ AI ագենտներն ավելի ու ավելի հաճախ են ինքնուրույն հավաքում օգտատիրոջ ինտերֆեյսները, դիզայն-համակարգերը օգտագործում որպես մեքենայաբար ընթեռնելի ենթակառուցվածք և սեմանտիկ տոկեններից կոդ ստեղծում, մենք մոտենում ենք մի հատման կետի, որն արձագանքում է հաշվողական տեսության շատ ավելի հին մի գաղափարի։

Ի՞նչ գաղափար։ Դիզայնը կոդն է։

Սա պարզապես գրավիչ խոսք չէ։ Սա այն գիտակցումն է, որ մենք գուցե շարժվում ենք դեպի մի աշխարհ, որտեղ դիզայն-համակարգերն աշխատում են որպես բջջային ավտոմատներ՝ պարզ կանոններ, որոնցից ծնվում են բարդ, ինքնաբուխ վարքագծեր։ Որտեղ «նախագծել» և «ծրագրավորել» բառերի սահմանը լիովին վերանում է։ Որտեղ ինքնավար ագենտները դիզայն-համակարգերը ոչ թե պարզապես օգտագործում են, այլ գործողության մեջ իրենք են դիզայն-համակարգը։

Այս բլոգային գրառումը ուսումնասիրում է բջջային ավտոմատների, ինքնաբուխ վարքագծի և ագենտային դիզայն-համակարգերի ապագայի խորը կապերը։ Մենք կհետևենք տեսական հիմքերին՝ ֆոն Նեյմանի ինքնավերարտադրվող մեքենաներից մինչև այսօրվա AI ագենտների երամները։

Կքննարկենք, թե ինչպես են Drupal-ը և ժամանակակից CMS հարթակները ինտեգրում AI-ն այնպիսի մոդուլների միջոցով, ինչպիսիք են Schema.org Blueprints-ը և Drupal AI-ը։ Եվ կփորձենք հասկանալ, թե այս ամենն ինչ է նշանակում դիզայներների, մշակողների և թվային արտադրանքի ստեղծման ապագայի համար։

Բջջային ավտոմատները և ինքնաբուխության տրամաբանությունը

Պարզ կանոնների գեղեցկությունը

1970 թվականին մաթեմատիկոս Ջոն Քոնուեյը ներկայացրեց «Կյանքի խաղը»՝ «զրո խաղացողով խաղ», որը հետագայում դարձավ հաշվողական տեսության ամենաուսումնասիրված համակարգերից մեկը։ Կանոնները շնչառության պես պարզ են.

1. Ցանկացած կենդանի բջիջ, որն ունի երկուսից քիչ կենդանի հարևան, մահանում է (թերբնակեցում)
2. Ցանկացած կենդանի բջիջ, որն ունի երկու կամ երեք կենդանի հարևան, գոյատևում է
3. Ցանկացած կենդանի բջիջ, որն ունի երեքից ավելի կենդանի հարևան, մահանում է (գերբնակեցում)
4. Ցանկացած մեռյալ բջիջ, որն ունի ճիշտ երեք կենդանի հարևան, կենդանանում է (վերարտադրություն)

Այս չորս կանոններից՝ արտահայտված մի բուռ երկուական պայմաններով, ծնվում է բարդության զարմանալի մի տիեզերք։ Սահիչները (gliders) անցնում են անվերջ ցանցերով։ Տատանիչները բաբախում են անդադար ռիթմերով։ «Թնդանոթները» նախշերի հոսքեր են արձակում բջջային տարածության մեջ։ Եվ ամենաուշագրավը՝ ապացուցված է, որ «Կյանքի խաղը» Թյուրինգ-լրիվ է. այն ամենը, ինչ կարելի է հաշվարկել ալգորիթմորեն, սկզբունքորեն կարելի է հաշվարկել Քոնուեյի այդ պարզ ցանցի ներսում։

Նկար 1. Գոսպերի սահող թնդանոթը Քոնուեյի «Կյանք» խաղում։ Այս կաղապարը անընդհատ սահուկների հոսք է արտադրում՝ ցույց տալով, թե ինչպես կարող են պարզ կանոնները ծնել անվերջ, ինքնապահպան բարդություն։

Սա բջջային ավտոմատների առաջին դասն է. բարդ վարքի համար բարդությունը նախապայման չէ։ Պարզ կանոնները, որոնք հետևողականորեն կիրառվում են ամբողջ միջավայրում, կարող են ծնել օրինաչափություններ և վարք, որոնք ոչ ոք բացահայտորեն չի ծրագրավորել։

Լենգթոնի օղակները և ինքնավերարտադրությունը

1984 թվականին Քրիստոֆեր Լենգթոնն այս սկզբունքն ավելի առաջ տարավ իր ինքնավերարտադրվող օղակներով. դա բջջային ավտոմատ էր, որը դրսևորում էր արհեստական կյանքի իսկական սկզբունքներ։ Ի տարբերություն Քոնուեյի «Կյանք» խաղի, որն ցույց է տալիս ծագող բարդությունը, Լենգթոնի օղակները ցույց են տալիս ծագող վերարտադրություն.

Յուրաքանչյուր օղակ կազմված է ցիկլային եզրագծից, որը պարփակում է բջիջների վիճակներում կոդավորված «գենոմ»։ Այս գենոմը անընդհատ հոսում է օղակի շուրջը և դուրս է գալիս շինարարական թևի երկայնքով, որը 151 ժամանակային քայլում կառուցում է դուստր օղակ։ Երբ այն ավարտվում է, դուստրը անջատվում է ծնողից, և երկուսն էլ շարունակում են վերարտադրվել։

Նկար 2. Լենգթոնի օղակը իր սկզբնական կազմաձևով։ Գենետիկ տեղեկատվությունը շրջանառվում է օղակում և ձգվող թևի միջոցով ուղղորդում դուստր օղակների կառուցումը։

«Եթե ինքնավերարտադրվող մեքենան հնարավոր է բջջային ավտոմատի մեջ, ապա հենց կյանքը կարող է իրագործելի լինել մեքենաների համար»։

- Քրիստոֆեր Լենգթոն, «Արհեստական կյանքի ուսումնասիրությունը բջջային ավտոմատների միջոցով» (1986)

Հետևանքները խորն են։ Լենգթոնի օղակները ցույց են տալիս, որ ինքնավերարտադրությունը չի պահանջում կենսաբանական բջիջների բարդությունը կամ ֆոն Նեյմանի սկզբնական նախագծի համընդհանուր կառուցման հնարավորությունները։ Այն պահանջում է միայն.

• Պարզ, տեղային կանոնների հավաքածու
• Հրահանգների կոդավորման մեխանիզմ
• Այն գործընթացը, որով այդ հրահանգները կատարվում են

Կանոնները հենց օրգանիզմն են։ Նախագիծը հենց կոդն է։

1999 թվականին Հիրոկի Սայաման ներկայացրեց էվոլուպները (evoloops)՝ տարբերակներ, որոնք ներառում են կառուցվածքային լուծելիություն և ֆենոտիպային փոխազդեցություններ՝ հնարավորություն տալով ինքնաբուխ մուտացիաների և էվոլյուցիոն դինամիկայի։ Այս օղակները զարգանում են վերարտադրության ընթացքում ուղղակի ֆիզիկական բախումների շնորհիվ, ինչը հանգեցնում է գենոտիպերի տատանումների, ձևաբանական բազմազանության աճի և սերունդներով բարդության մեծացման։ Ի տարբերություն Լենգթոնի ֆիքսված վերարտադրության՝ էվոլուպները ցուցադրում են ժառանգվող մուտացիաներ առանց արտաքին միջամտության։

Կանոն 110-ը և համընդհանուր հաշվարկը

Սթիվեն Վոլֆրամի՝ տարրական բջջային ավտոմատների ուսումնասիրությունն ավարտվեց ապշեցուցիչ հայտնագործությամբ. Կանոն 110-ը, որը միաչափ բջջային ավտոմատի ամենապարզ տեսակի համար հնարավոր ընդամենը 256 կանոններից մեկն է, ընդունակ է համընդհանուր հաշվարկի։

Կանոն 110-ը կարելի է ամբողջությամբ սահմանել՝ նշելով արդյունքը ութ հնարավոր զուգակցումներից յուրաքանչյուրի համար, որոնք կազմում են բջիջն ու նրա երկու հարևանները։ Սակայն այս աննշան պարզ կանոնը՝ ութ երկուական որոշում, կարող է մոդելավորել ունիվերսալ Թյուրինգի մեքենա։

Նկար 3. Կանոն 110 բջջային ավտոմատ։ Չնայած պարզ սահմանմանը՝ Կանոն 110-ը դրսևորում է 4-րդ դասի վարքագիծ՝ բարդ նախշեր, որոնք ո՛չ լիովին կայուն են, ո՛չ լիովին քաոսային, և ապացուցված է, որ այն Թյուրինգ-լրիվ է։

«Ունիվերսալ հաշվարկի համար բնավ պետք չէ ամբողջ համակարգչային պրոցեսոր։ Պետք է պարզապես այս փոքրիկ կանոնը»։

- Սթիվեն Վոլֆրամ, «A New Kind of Science»

2004 թվականին Մեթյու Կուկը հրապարակեց ապացույց, որ Կանոն 110-ը՝ որոշակի կրկնվող ֆոնային նախշով, Թյուրինգ-լրիվ է։ Ապացույցը ցույց է տալիս, որ Կանոն 110-ը կարող է նմանակել ցիկլային թեգերի համակարգեր, որոնք էլ իրենց հերթին կարող են նմանակել ցանկացած Թյուրինգի մեքենա։ 88 հնարավոր եզակի տարրական բջջային ավտոմատների մեջ Կանոն 110-ը միակն է, որի Թյուրինգ-լրիվությունն ուղղակիորեն ապացուցված է։

Հաշվողական համարժեքության սկզբունքը, որ առաջարկել է Վոլֆրամը, ենթադրում է ավելի արմատական բան. բարդության նվազագույն շեմից վերև գտնվող համակարգերը, ըստ էության, համարժեք են իրենց հաշվողական հնարավորություններով։ Մարդու ուղեղը, եղանակային համակարգը և Կանոն 110-ը ինչ-որ խոր իմաստով հաշվողական առումով համարժեք են։

0E0P մետաբջիջը. իսկական ինքնավերարտադրություն

2018 թվականի հոկտեմբերին Ադամ Պ. Գուչերը ավարտեց 0E0P մետաբջջի կառուցումը. սա Քոնուեյի «Կյանքի խաղի» նախշ է, որն ունակ է իսկական ինքնավերարտադրության։ Ի տարբերություն նախորդ մետաբջիջների, որոնց մոտակայքում անհրաժեշտ էին նախապես գոյություն ունեցող օրինակներ, 0E0P մետաբջիջը կարող է զրոյից կառուցել իր պատճենները, այդ թվում՝ սեփական հրահանգների ժապավենը։

Այս ձեռքբերումը նշանավորում է արհեստական կյանքի հանգրվան. համակարգ, որը կարող է տարածվել հաշվողական միջավայրում՝ օգտագործելով միայն տեղային կանոններ։ 2013 թվականի նոյեմբերի 23-ին Դեյվ Գրինը «Կյանքի խաղում» կառուցեց առաջին ռեպլիկատորը, որը ստեղծում է իր ամբողջական պատճենը, այդ թվում՝ հրահանգների ժապավենը՝ ցույց տալով, որ նույնիսկ Քոնուեյի պարզ երկվիճակ ավտոմատը կարող է ապահովել անսահմանափակ ինքնավերարտադրություն։

Դիզայն-համակարգերը՝ որպես հաշվողական միջավայր

Ատոմային դիզայնից՝ դեպի գործակալային դիզայն

Բրեդ Ֆրոստի Atomic Design մեթոդաբանությունը, որ ներկայացվել է 2013 թվականին, հեղաշրջեց դիզայն-համակարգերի մասին մեր պատկերացումը։ Ինտերֆեյսները բաժանելով ատոմների (հիմնական տարրեր, ինչպիսիք են կոճակներն ու մուտքագրման դաշտերը), մոլեկուլների (պարզ համակցություններ), օրգանիզմների (UI-ի բարդ հատվածներ), ձևանմուշների (էջերի դասավորություններ) և էջերի (վերջնական իրականացումներ)՝ Atomic Design-ը ստեղծեց բարդությունը կառավարելու աստիճանակարգային կառուցվածք։

Բայց ահա թե ինչն է ետադարձ հայացքով ուշագրավ. Atomic Design-ը արդեն իսկ մարմնավորում էր բջջային ավտոմատների սկզբունքները, թեև դրանք բացահայտորեն չէր ընդունում։

«Երբ դիզայն-համակարգը ձանձրալի է, այն ազատում է դիզայներներին և մշակողներին՝ զբաղվելու նորով, լուծելու նոր խնդիրներ։ Դիզայն-համակարգը վերցնում է ձանձրալիի բեռը, որպեսզի դիզայներներն ու մշակողները այն չկրեն։»

- Ջոշ Քլարկ, «Ամենահետաքրքիր դիզայն-համակարգերը ձանձրալի են»

2023 թվականի փետրվարին Բրեդ Ֆրոստը գրել է «Դիզայն-համակարգերը արհեստական բանականության դարաշրջանում» թեմայով.

«Արհեստական բանականությունը դիզայն-համակարգի բնական սպառող է... Փաստն այն է, որ դիզայն-համակարգի բաղադրիչների վրա աշխատանքի մեծ մասը իրականում մեխանիկական է և կանխատեսելի։ Մենք արդեն օգտագործում ենք PlopJS-ի նման գործիքներ՝ գրադարանի մյուս մասերին համապատասխան բաղադրիչի բոյլերփլեյթ արագ ստեղծելու համար։ Ես ուրախ կլինեի, եթե AI-ն օգներ ինձ գեներացնել սովորական բոյլերփլեյթների մեծ մասը։»

- Բրեդ Ֆրոստ

Դիզայն-համակարգերի մեխանիկական և կանխատեսելի բնույթը հենց այն է, ինչը դրանք դարձնում է հարմար բջջային ավտոմատների ոճով աշխատանքի համար։ Երբ կանոնները հստակ են, տեղային և հետևողականորեն կիրառվող, գործակալները կարող են գործել ինքնուրույն. ճիշտ ինչպես Քոնուեյի «Կյանք» խաղի բջիջներին կենտրոնական կառավարիչ պետք չէ՝ սահողներ ու տատանիչներ ստեղծելու համար։

Մեքենայով ընթեռնելիության անհրաժեշտությունը

Storybook MCP-ի (Model Context Protocol) նախաձեռնությունը այս ուղղությամբ կարևոր քայլ է։ 2025 թվականի վերջին հայտարարված Storybook MCP-ն AI կոդավորման գործակալներին տրամադրում է մեքենայով ընթեռնելի մետատվյալներ բաղադրիչների մասին՝ ստացված արդեն գործող Storybook կարգավորումներից։

Գլխավոր դիտարկումն այն է, որ գործակալներին հում կոդ կամ տեսողական փաստաթղթեր պետք չեն։ Նրանց անհրաժեշտ է.

• Բաղադրիչների մանիֆեստներ. կառուցվածքային մետատվյալներ յուրաքանչյուր բաղադրիչի մասին՝ նրա props-երը, տարբերակները, դիզայնի թոքենների կապերը և օգտագործման օրինակները
• Իմաստային անվանում. նպատակը արտահայտող թոքեններ, ինչպիսին է action.primary.confirm, որոնք գործակալներին փոխանցում են իմաստ, ոչ թե պարզապես արժեքներ
• Վավերացման օղակներ. թեստեր գործարկելու, ձախողումները տեսնելու և ինքնուրույն ուղղվելու հնարավորություն

«Storybook MCP-ն օգնում է գործակալներին հետևել ձեր օրինաչափություններին և անցնել ձեր թեստերը։ Այն նրանց տալիս է երկու բան, որ նրանք երբեք չեն ունեցել. բաղադրիչների մեքենայով ընթեռնելի մետատվյալներ և կրկնվող օղակ՝ սխալներն ինքնուրույն բուժելու համար։»

- Storybook-ի թիմ

Storybook MCP-ն ներառում է ինքնավար ուղղման օղակ։ Այն թույլ է տալիս գործակալներին գործարկել ձեր բաղադրիչների թեստերը (փոխազդեցության և մատչելիության), տեսնել, թե ինչն է ձախողվում, և ուղղել սեփական սխալները։ Մշակողը պետք է միջամտի միայն այն բանից հետո, երբ թեստերն անցնեն։ Այլևս պրոմպտերի վրա «դայակություն» անել պետք չէ։

Սա հենց բջջային ավտոմատի ճարտարապետությունն է, կիրառված դիզայնի վրա. տեղային կանոններ (բաղադրիչների սպեցիֆիկացիաներ), հարևանների փոխազդեցություններ (կոմպոզիցիայի օրինաչափություններ) և կրկնվող թարմացումներ (վավերացում և ինքնուղղում)։

Բաղադրիչի մանիֆեստը որպես գենոմ

Լենգթոնի օղակների հետ համեմատությունն ավելի տեղին է դառնում, երբ դիտարկում ենք, թե ինչպես են աշխատում բաղադրիչների մանիֆեստները։ Լենգթոնի համակարգում շրջանառվող բջիջներում կոդավորված «գենոմը» պարունակում է նոր օղակ կառուցելու հրահանգները։ Մեքենայով ընթեռնելի դիզայն-համակարգում բաղադրիչի մանիֆեստը պարունակում է ինտերֆեյսներ հավաքելու հրահանգները։

Բաղադրիչի մանիֆեստը կարող է սահմանել.

{
  "name": "Button",
  "variants": ["primary", "secondary", "destructive"],
  "sizes": ["sm", "md", "lg"],
  "props": {
    "label": "string",
    "disabled": "boolean",
    "onClick": "function"
  },
  "tokens": {
    "background": "color.action.primary",
    "borderRadius": "radius.md",
    "padding": "space.3"
  },
  "constraints": [
    "Must have accessible contrast ratio",
    "Label required for non-icon buttons",
    "Minimum touch target 44x44px"
  ],
  "examples": [
    { "variant": "primary", "label": "Submit", "size": "md" },
    { "variant": "destructive", "label": "Delete", "size": "sm" }
  ]
}

Այս մանիֆեստը միաժամանակ և դիզայնի սպեցիֆիկացիա է, և կատարվող կոդ, կամ ավելի ճիշտ՝ հրահանգների մի հավաքածու, որից կարելի է գեներացնել կատարվող կոդ։ Այս մանիֆեստը օգտագործող գործակալին պետք չէ հասկանալ գեղագիտությունը կամ օգտատիրոջ փորձառությունը այն իմաստով, ինչպես մարդն է հասկանում։ Նրան պետք է հետևել կանոններին, համադրել տարրերը՝ ըստ դրանց սահմանափակումների, և ստանալ վավեր արդյունք։

Ես համաձայն եմ Բրեդ Ֆրոստի հետ, որ պետք է օգտագործել yaml ձևաչափը։

Drupal-ի կոմպոնենտներն օգտագործում են yaml ձևաչափը։ Մոտավորապես այսպես՝

$schema: https://git.drupalcode.org/project/drupal/-/raw/HEAD/core/assets/schemas/v1/metadata.schema.json
name: Button
status: experimental
description: Use Bootstrap custom button styles for actions in forms, dialogs, and more with support for multiple sizes, states, and more.
props:
  type: object
  properties:
    html_tag:
      type: string
      title: The HTML tag to use for the button (button | a). Defaults to `button`.
      default: button
      enum:
        - button
        - a
    url:
      type: string
      title: URL Link
      description: URL link for the button when the HTML tag is an anchor link.
      $ref: "ui-patterns://url"
    color:
      type: string
      title: Color
      description: Bootstrap includes several predefined button styles, each serving its own semantic purpose, with a few extras thrown in for more control.
      default: ''
      enum:
        - ''
        - primary
        - secondary
        - success
        - danger
        - warning
        - info
        - dark
        - light
        - link
    outline:
      type: boolean
      title: Outline
      description: In need of a button, but not the hefty background colors they bring? Replace the default modifier classes with the .btn-outline-* ones to remove all background images and colors on any button.
      default: false
    size:
      type: string
      title: Size
      description: Bootstrap button size
      default: ''
      enum:
        - ''
        - btn-sm
        - btn-lg
    disabled:
      type: boolean
      title: Disabled
      description: Disabled button
      default: false
    button_utility_classes:
      type: array
      title: Utility Classes
      default: []
      items:
        type: 'string'
      description: An array of utility classes that can be used to add extra Bootstrap utility classes or custom classes to this component.
    attributes:
      type: object
      title: Attributes
      description: HTML attributes for the containing element.
      $ref: 'ui-patterns://attributes'
slots:
  content:
    type: string
    title: Content
    description: The content for the button
    minLength: 1
    examples:
      - Press
      - Submit now
      - Save
      - Login
      - Read more

Դիզայնը հենց կոդն է։

• Տարբերակներ (Variants)
• Թոքեններ (Tokens)
• Հատկություններ (Props)

• Սահմանափակումներ (Constraints) (կարող ենք ավելացնել կոմպոնենտներին)

• Սլոթերի կանոններ (ինչը կարելի է տեղադրել այլ սլոթերում, կամ ինչը թույլատրվում է տեղադրել իմ սլոթում)

• Կանոններ

• Օրինակներ 

• Անիմացիաներ  ( Թույլատրված կամ առաջարկվող օգտագործման համար )

Ապա դիտեք և փորձարկեք վարքագիծը։

ինչպես https://storybook.demo.varbase.vardot.com/?path=/story/atoms-button--primary 

Դիզայնի թոքենները՝ որպես միջավայրի փոփոխականներ

Դիզայնի թոքենները հանելուկի մեկ այլ կարևոր մասն են։ Բջջային ավտոմատներում բջիջները արձագանքում են իրենց անմիջական միջավայրին՝ հարևան բջիջների վիճակներին։ Դիզայնի համակարգերում կոմպոնենտները արձագանքում են դիզայնի թոքեններին՝ այն համատեքստային արժեքներին, որոնք որոշում են նրանց տեսքն ու վարքը։

Ժամանակակից թոքենային ճարտարապետությունները օգտագործում են մի քանի շերտ՝

• Հիմնական թոքեններ՝ հում արժեքներ, ինչպիսին է color.blue.500: #3B82F6
• Իմաստային թոքեններ՝ նպատակով պայմանավորված հղումներ, ինչպիսին է color.action.primary: color.blue.500
• Կոմպոնենտի թոքեններ՝ կոնկրետ կոմպոնենտին վերաբերող կիրառություններ, ինչպիսին է button.background.primary: color.action.primary

Երբ գործակալը գեներացնում է Button կոմպոնենտ, նրան պետք չէ իմանալ, որ «primary»-ն նշանակում է կապույտ։ Բավական է հղվել button.background.primary և վստահել, որ թոքենների համակարգը կորոշի ճիշտ արժեքը։ Միջավայրը (թոքենների շերտը) պարունակում է տեղեկատվությունը, իսկ կոմպոնենտը (բջիջը) պարզապես պետք է արձագանքի դրան։

Այնպիսի գործիքներ, ինչպիսին է Tokens Studio-ը, զարգացել են այնպես, որ դիզայնի թոքեններին վերաբերվում են որպես հաշվողական գրաֆների՝ ռեզոլվերներով, այսինքն՝ հանգույցներով, որոնք համատեքստից ելնելով իմաստային որոշումներ են կայացնում, թե որ հիմնական թոքենները օգտագործել։ Սա դիզայնի թոքենները ստատիկ արժեքներից վերածում է դինամիկ, կանոններով առաջնորդվող համակարգերի։

Drupal-ի էկոհամակարգը և արհեստական բանականության ինտեգրումը

Արհեստական բանականության ինտեգրումը բովանդակության կառավարման համակարգերին (CMS) կատարյալ լաբորատորիա է «դիզայնը կոդն է» սկզբունքները ուսումնասիրելու համար։ Drupal-ի նման CMS-ներն արդեն իսկ մարմնավորում են հիմնական հասկացությունները՝ կառուցվածքավորված բովանդակության տիպեր, դաշտերի սահմանումներ, կապեր և կազմման կանոններ։

Երբեք չէի մտածի, որ կարող ենք նման բան ասել։ Ինձ համար սա արվեստի գագաթնակետ էր։

 Ամենակատարյալ համակարգչային հավաքածուն, որը կարող էինք ունենալ։ Մի քանի ծրագրավորողներ, ասես գալիս են ապագայի «Star Trek»-ից և համակարգչի հետ խոսելով ստիպում են, որ այն ծրագրավորի իրենց փոխարեն։

Գործակալի փորձառությունը (AX) և նոր օգտատերը

Դիզայն մեքենաների համար

2025 թվականի սկզբին Netlify-ի գործադիր տնօրեն Մաթիաս Բիլմանը ներկայացրեց «Գործակալի փորձառություն» (AX) հասկացությունը՝ նոր ուղղություն, որը կենտրոնանում է այն բանի վրա, թե ինչպես են արհեստական բանականության գործակալները շփվում ապրանքների և հարթակների հետ։

Տեղաշարժը հիմնարար է։ Տասնամյակներ շարունակ UX-ը (օգտատիրոջ փորձառությունը) օպտիմալացվում էր մարդու ընկալման, զգայության և վարքի համար։ DX-ը (ծրագրավորողի փորձառությունը) օպտիմալացվում էր ծրագրային ապահովում ստեղծող մարդ ծրագրավորողների համար։ AX-ը ընդունում է, որ գործակալները դառնում են թվային համակարգերի հիմնական օգտատերերը, և նրանց կարիքները լրիվ այլ են՝

• Նրանց չի հետաքրքրում տեսողական գեղագիտությունը․ նրանց պետք են միայն կառուցվածքավորված, վերլուծելի տվյալներ
• Նրանք ինտերֆեյսներում չեն նավարկում․ նրանք կանչում են API-ներ և օգտագործում մանիֆեստներ
• Նրանք փաստաթղթերը չեն կարդում մարդու նման․ նրանց պետք է մեքենայի համար ընթեռնելի համատեքստ
• Նրանք սուբյեկտիվ դատողություններ չեն անում․ նրանք հետևում են կանոններին և սահմանափակումներին

«AI գործակալները մարդիկ չեն. նրանց չի հետաքրքրում կոճակի չափը, տառատեսակի ընթեռնելիությունը, ձեր կայքի գեղեցիկ գունապնակը կամ հավելվածի աչքի զարնող անիմացիաները։ Ուրեմն ի՞նչն է «հետաքրքրում» AI գործակալներին։ Այս հարցը այսօր հստակ պատասխան չունի, բայց առաջիկա տարիներին գնալով ավելի կարևոր է դառնալու։»

- AX հետազոտություն

Պատասխանը՝ հստակ կանոններ, կանխատեսելի վարք, լավ կառուցվածքով տվյալներ և հետադարձ կապի ցիկլեր, որոնք թույլ են տալիս գործակալներին ստուգել և ուղղել իրենց գործողությունները։

Երկակի ինտերֆեյսի մարտահրավերը

AX-ի համար նախագծելը նշանակում է միաժամանակ երկու ինտերֆեյս կառուցել․

1. Մարդ–գործակալ ինտերֆեյս․ այն շերտը, որտեղ մարդիկ հսկում, հաստատում, խմբագրում և ուղղորդում են գործակալի վարքը՝ «առաքելության կառավարման կենտրոնը»։ Մտածեք վահանակների և հաստատման հերթերի մասին, ոչ թե ձևերի և կոճակների։
2. Գործակալ–համակարգ ինտերֆեյս․ այն շերտը, որտեղ գործակալները աշխատում են API-ների, տվյալների բազաների և գործիքների հետ՝ «գործառնական» շերտը։ Այն պետք է լինի կայուն, լավ փաստաթղթավորված և օպտիմիզացված մեքենայի արդյունավետության համար։

Սա արտացոլում է բջջային ավտոմատների կառուցվածքը, որտեղ համագոյակցում են երկու տարբեր հայեցակետեր․

• Առաջինը՝ տեղային հայեցակետը։ Յուրաքանչյուր բջիջ (գործակալ) հետևում է պարզ կանոնների՝ ելնելով իր անմիջական հարևաններից
• Երկրորդը՝ գլոբալ հայեցակետը։ Ի հայտ են գալիս բարդ օրինաչափություններ, որոնք տեսանելի են միայն մեծ մասշտաբով

«Գործակալի փորձի դիզայնը (AX) պետք է ապահովի գերազանց օգտագործելիություն գործակալների համար և նրանց կողմից։ Այսպիսով, լավ AX-ը հանգեցնում է լավ օգտագործողի փորձի (UX)։ Եթե AI գործակալը հանդիպում է կոտրված գործընթացի, արձանագրության կամ նույնիսկ համակարգերի միջև անհամապատասխան ձևակերպումների, նա չի կարողանում կատարել առաջադրանքը։ Դա վատ փորձ է գործակալի համար, որն իր հերթին հանգեցնում է հաճախորդի կամ աշխատակցի վատ փորձի։»

- Քեթ Հոլմս, Salesforce-ի գլխավոր փորձի պատասխանատու (Chief Experience Officer)

UX-ից AX․ թվային դիզայնի էվոլյուցիան

Ստիգմերգիա և անուղղակի հաղորդակցություն

Երամային բանականության ամենահզոր հասկացություններից մեկը ստիգմերգիան է՝ շրջակա միջավայրի հետքերի միջոցով անուղղակի համակարգումը։ Մրջյունները սննդի տեղի մասին ուղղակիորեն չեն հաղորդակցվում․ նրանք թողնում են ֆերոմոնային հետքեր, որոնց հետևում են մյուսները։ Միջավայրը դառնում է հաղորդակցման միջոց։

Գործակալային դիզայնի համակարգերում ստիգմերգիան դրսևորվում է հետևյալ կերպ․

• Ընդհանուր բաղադրիչների գրադարաններ․ գործակալները «տեսնում են», թե որ բաղադրիչներն են գոյություն ունեն և ինչպես են դրանք օգտագործվել
• Design token-ներ․ իմաստային արժեքներ, որոնք դիզայնի որոշումները կոդավորում են որպես միջավայրի փաստեր
• Օրինաչափությունների փաստաթղթավորում․ օգտագործման օրինակներ, որոնք ապագա գործակալների համար ծառայում են որպես ֆերոմոնային հետքեր
• Թեստերի փաթեթներ․ վավերացման կանոններ, որոնք սահմանափակում են ճիշտ արդյունքների տարածությունը
• Git պատմություն․ անցյալ որոշումների գրառում, որին գործակալները կարող են դիմել

Երբ գործակալը բաղադրիչի միջոցով UI է ստեղծում, նա հետքեր է թողնում՝ կոդի բազայում, փաստաթղթերում, իր հաստատած օրինաչափություններում։ Նմանատիպ խնդիրների հանդիպող հետագա գործակալները կազդվեն այդ հետքերից՝ ստեղծելով կոլեկտիվ բանականության մի ձև, որը չունի ոչ մի առանձին գործակալ։

Գործակալային դիզայնի օրինաչափություններ

Էնդրյու Նգը և այլ մասնագետներ առանձնացրել են գործակալային AI համակարգերի չորս հիմնական օրինաչափություն․

1. Ռեֆլեկսիա․ AI-ն գնահատում է սեփական արդյունքը և քայլ առ քայլ բարելավում այն
2. Գործիքների օգտագործում․ AI-ն աշխատում է արտաքին գործիքների, API-ների և համակարգերի հետ
3. Պլանավորում․Արհեստական բանականությունը բարդ խնդիրները բաժանում է ենթախնդիրների և կատարում դրանք հաջորդաբար
4. Բազմագործակալ համակարգեր՝ բարդ խնդիրների շուրջ համագործակցում են մի քանի մասնագիտացված գործակալներ

Այս օրինաչափությունները ուղղակիորեն համապատասխանում են բջջային ավտոմատների հասկացություններին՝

Դիզայնը կոդն է. խորքային ընթերցում

Ինչ է իրականում նշանակում «դիզայնը կոդն է»

Երբ ասում ենք «դիզայնը կոդն է», միաժամանակ մի քանի պնդում ենք անում՝

1. Իմաստային համարժեքություն

Դիզայնի որոշումները, երբ ճիշտ են կոդավորված, դառնում են կատարելի։ Դիզայն-թոքենը պարզապես արժեք չէ, այլ հրահանգ։ Կոմպոնենտի սպեցիֆիկացիան պարզապես փաստաթուղթ չէ, այլ ծրագիր։ Երբ գործակալները օգտագործում են այս արտեֆակտները, նրանք նույնքան կատարում են դիզայնը, որքան իրագործում։

2. Գեներատիվ կարողություն

Ինչպես Rule 110-ը կարող է հաշվարկել ամեն ինչ, ինչ հաշվարկելի է, այնպես էլ բավարար չափով ամբողջական դիզայն-համակարգը կարող է ստեղծել ցանկացած վավեր ինտերֆեյս։ Համակարգը պարունակում է իր բոլոր վավեր դրսևորումների հնարավորությունը։ Թե ինչ կծնվի, կախված է միայն սկզբնական պայմաններից (պահանջներից) և կանոններից (սահմանափակումներից)։

3. Էմերջենտ բարդություն

Ամենաբարդ ինտերֆեյսները նախագծվում են ոչ թե վերևից ներքև, այլ ծնվում են պարզ կանոնների հետևողական կիրառումից։ Լավ նախագծված կոճակը, հետևողականորեն օգտագործվելով, ստեղծում է համահունչ տեսողական լեզու՝ առանց որևէ մեկի այդ համահունչությունը հստակ պլանավորելու։

4. Հաշվողական անկրճատելիություն

Դիզայնի որոշ արդյունքներ հնարավոր չէ կանխատեսել առանց համակարգն իրականում գործարկելու։ Չես կարող իմանալ, թե ինչ տեսք կունենա գործակալի հավաքած ինտերֆեյսը, քանի դեռ գործակալին թույլ չես տվել այն հավաքել։ Սա Վոլֆրամի հաշվողական անկրճատելիության սկզբունքն է՝ կիրառված դիզայնի նկատմամբ։

5. Ինքնափոփոխում

Ինչպես evoloop-ները, որոնք վերարտադրվելիս մուտացիայի են ենթարկվում, այնպես էլ գործակալների համար պատրաստ դիզայն-համակարգերը կարող են զարգանալ օգտագործման ընթացքում։ Գործակալների ստեղծած կոմպոնենտները դառնում են գրադարանի մաս, որը կօգտագործեն ապագա գործակալները։ Համակարգը սովորում է, հարմարվում և աճում։

Բջջային ավտոմատների փոխաբերության շարունակությունը

Փոխաբերությունից այն կողմ. իրական մերձեցում

Բայց սա պարզապես փոխաբերություն չէ։ Մերձեցումն իրական է և տեղի է ունենում հենց հիմա՝

• Storybook MCP կոմպոնենտների գրադարանները վերածում է մեքենայաբար ընթեռնելի հրահանգների, որոնք կատարում են գործակալները
• Model Context Protocol միասնականացնում է, թե ինչպես են գործակալները հասանելիություն ստանում գործիքներին և համատեքստին՝ ստեղծելով ունիվերսալ հիմք գործակալային գործողությունների համար
• Բազմագործակալ ճարտարապետություններ աշխատանքը բաժանում են մասնագիտացված գործակալների միջև (ճարտարապետ, կոդավորող, վերանայող), որոնք փոխազդում են ըստ արձանագրությունների՝ ինչպես տարբերակված գործառույթներով բջիջները
• Ինքնաբուժվող ցիկլերը թույլ են տալիս գործակալներին թեստեր անցկացնել, սխալներ հայտնաբերել և կրկնել փորձը՝ նույն հետադարձ կապի մեխանիզմներով, որոնք բջջային ավտոմատներն օգտագործում են կայուն կոնֆիգուրացիաներ ձևավորելու համար
• Schema.org Blueprints բովանդակության կառուցվածքները դարձնում են մեքենայաընթեռնելի և իմաստային առումով հստակ
• Drupal AI ապահովում է այն ենթակառուցվածքը, որով AI գործակալները կարող են ինքնուրույն ստեղծել, փոփոխել և կառավարել բովանդակություն

Մենք «դիզայնը կոդն է» սկզբունքին չենք մոտենում որպես փիլիսոփայական դիրքորոշման։ Մենք այն կառուցում ենք որպես տեխնիկական ենթակառուցվածք։

Հետևանքները և առջևի ճանապարհը

Դիզայներների համար

Դիզայների դերը փոխվում է՝ «ուղղանկյուն ստեղծողից» դառնալով «կանոն սահմանող»։ Ինչպես նկատել է Բրեդ Ֆրոստը (Brad Frost).

«Դիզայներներն ու ծրագրավորողները, որոնք իրենց գործը պատկերացնում են որպես ուղղանկյուններ ստեղծել, շատ պատճառներ ունեն անհանգստանալու։ Իսկ նրանք, ովքեր իրենց գործը տեսնում են որպես խնդիրների լուծում՝ և միայն պատահաբար են ստիպված լինում ուղղանկյուններ ստեղծել կամ կիրառել այդ խնդիրները լուծելու համար, վախենալու պատճառ քիչ ունեն։»

- Brad Frost

Գործակալային ապագայում դիզայներները՝

• կսահմանեն իմաստային թոքեններ (tokens) և դրանց փոխհարաբերությունները
• կհաստատեն կոմպոզիցիայի սահմանափակումներ և նախշեր
• կստեղծեն վավերացման կանոններ, որոնց գործակալները պետք է բավարարեն
• կընտրեն և կզարգացնեն այն կանոնները, որոնք կառավարում են ինքնաբուխ առաջացումը (emergence)
• կնախագծեն հետադարձ կապի մեխանիզմներ, որոնք ապահովում են ինքնաուղղում
• կձևավորեն «պիտանիության ֆունկցիաներ» (fitness functions), որոնք որոշում են, թե որ արդյունքներն են ընդունելի

Սա դիզայն է աբստրակցիայի ավելի բարձր մակարդակում՝ նախագծել այն կանոնները, որոնք ծնում են դիզայններ, այլ ոչ թե հենց դիզայնները։ Ասես սահմանես բջջային ավտոմատի կանոնները, փոխանակ յուրաքանչյուր բջիջ առանձին-առանձին նկարելու։

Ծրագրավորողների համար

Ծրագրավորողները դառնում են գործակալային համակարգերի ճարտարապետներ։ Ինչպես նկարագրում է Anthropic-ը.

«Ծրագրային ապահովման մշակման ոլորտը ցուցաբերել է LLM հնարավորությունների ուշագրավ ներուժ. կոդի ավարտումից այդ հնարավորությունները զարգացել են մինչև ինքնուրույն խնդիրներ լուծելը։»

Ծրագրավորողներին անհրաժեշտ կլինի՝

• ստեղծել մեքենայաընթեռնելի ինտերֆեյսներ գործակալների և համակարգերի միջև
• նախագծել հետադարձ կապի օղակներ և վավերացման մեխանիզմներ
• կառուցել այն հենակառույցը, որի ներսում տեղի է ունենում ինքնաբուխ վարքը
• պահպանել մարդկային վերահսկողությունը որպես վերջնական իրավարար
• սահմանել այն արձանագրությունները, որոնցով գործակալները շփվում են
• իրականացնել «սոսնձող կոդը» (glue code), որը կապում է գործակալային տարբեր համակարգեր

Վեբ մշակման և CMS հարթակների համար

AI-ի ինտեգրումը Drupal-ի նման հարթակներում մատնանշում է մի ապագա, որտեղ՝

• Բովանդակության մոդելները դառնում են գործակալների համար մատչելի Schema.org-ի նման ստանդարտների շնորհիվ
• Խմբագրական աշխատանքային հոսքերը դառնում են գործակալների աջակցությամբ AI-ով սնուցվող սևագրման, մոդերացիայի և օպտիմիզացման միջոցով
• Որոնումը զարգանում է բանալի բառերի համընկնումից դեպի իմաստային ընկալում՝ embeddings-ների և վեկտորային տվյալների բազաների միջոցով
• Անհատականացումը դառնում է ինքնավար գործակալները սովորում են օգտատիրոջ նախասիրությունները և իրական ժամանակում հարմարեցնում բովանդակությունը
• Մշակումը արագանում է քանի որ գործակալները գեներացնում են կոմպոնենտներ, թեստեր և փաստաթղթեր

Drupal էկոհամակարգի ձգտումը դեպի AI՝ Drupal AI, Drupal Canvas, Schema.org Blueprints մոդուլների և AI մատակարարների ինտեգրման միջոցով, ցույց է տալիս, որ այս ապագան արդեն կառուցվում է։

Կազմակերպությունների համար

Մրցակցային առավելությունը կպատկանի այն կազմակերպություններին, որոնց դիզայն-համակարգերն առավել «պատրաստ են գործակալների համար»։ Գործակալներին պատրաստ համակարգերն ունեն՝

• կոմպոնենտների վիճակների և տարբերակների լիարժեք ընդգրկում
• իմաստային անվանումներ, որոնք արտահայտում են մտադրությունը
• մեքենայաընթեռնելի փաստաթղթեր և համատեքստ
• վավերացման և թեստավորման ենթակառուցվածք
• հստակ սահմանափակումներ, որոնք շրջանակում են վավեր արդյունքների տարածությունը
• գործակալների սպառման համար նախագծված API-ներ (AX-first)
• Schema.org-ը առաջնային դարձնող բովանդակային ճարտարապետություններ

Թվային արտադրանքների ապագայի համար

Վերջնական վիճակը նման է թվային էկոլոգիայի. անթիվ գործակալներ, որոնք գործում են տեղային կանոններով և ստեղծում են ի հայտ եկող ինտերֆեյսներ. դրանք չի պլանավորել ո՛չ մի դիզայներ կամ մշակող, բայց դրանք ինչ-որ կերպ համահունչ են, քանի որ հիմքում ընկած կանոնները ճիշտ են։

Սա այնքան էլ հեռու չէ իրականությունից, որքան թվում է։ Հենց այսպես են աշխատում կենսաբանական համակարգերը, աճում քաղաքները, գործում շուկաները։ Հարցն այն չէ, թե կհասնե՞նք այս վիճակին, այլ թե ինչպես կանցնենք այդ անցումը։

Եզրակացություն. կոդը կենդանի է

Ջոն ֆոն Նեյմանը՝ բազմակողմանի գիտնականը, ով հորինեց բջջային ավտոմատները, առաջնորդվում էր մի հիմնարար հարցով. Ո՞րն է ինքնավերարտադրության համար անհրաժեշտ նվազագույն բարդությունը։ Նրա պատասխանը՝ ֆոն Նեյմանի ունիվերսալ կառուցիչը, ցույց տվեց, որ ինքնակրկնօրինակումը կենսաբանական մեխանիզմներ չի պահանջում։ Բավական են միայն այն կանոնները, որոնք կոդավորում են սեփական կիրառումը։

Յոթանասուն տարի անց մենք հայտնաբերում ենք, որ նույն սկզբունքը գործում է նաև դիզայն-համակարգերում։ Ինտերֆեյսի ինքնավար գեներացման նվազագույն պայմանը ո՛չ արհեստական ընդհանուր բանականությունն է, ո՛չ էլ մարդու մակարդակի ստեղծագործականությունը։ Դա լիարժեք, հետևողական և մեքենայի համար ընթեռնելի կանոնների հավաքածու է, որը գործակալները կարող են կատարել։

Երբ Լենգթոնի օղակները կրկնօրինակվում են բջջային ցանցով մեկ, մենք չենք ասում, թե օղակները նոր օղակներ են «նախագծում»։ Կրկնօրինակումը պարզապես այն է, ինչ արտադրում են կանոնները։ Բայց արդյունքը՝ ինքնանման նախշերի անընդհատ ընդարձակվող գաղութները, անկասկած գեներատիվ է և ինչ-որ ֆունկցիոնալ իմաստով՝ ստեղծագործական։

Երբ AI գործակալները ինտերֆեյսներ են հավաքում դիզայն-համակարգի բաղադրիչներից՝ հետևելով սեմանտիկ թոքեններին և կոմպոզիցիայի սահմանափակումներին, նրանք անում են նման մի բան։ «Ստեղծագործականությունը» գործակալների մեջ չէ, այլ նրանց կատարած կանոնների՝ կանոններ, որոնք մարդիկ են նախագծել, բայց որոնք այժմ գործում են ինքնավար։

Մենք կանգնած ենք թվային ստեղծագործության նոր դարաշրջանի շեմին։ Գործակալներն արդեն այստեղ են։ Արձանագրությունները ձևավորվում են։ Դիզայն-համակարգերը դառնում են արհեստական կյանքի հիմք։

Դիզայնը կոդն է։
Իսկ կոդը կենդանանում է։

Հիմնական հոդվածներ և նախագծեր

• Դիզայն-համակարգերը AI-ի ժամանակաշրջանում - Բրեդ Ֆրոստ
• Storybook MCP. առաջին հայացք - Storybook
• Ներկայացնում ենք AX-ը. ինչու է կարևոր գործակալի փորձառությունը - Մաթիաս Բիլման
• Արդյունավետ գործակալների ստեղծում - Anthropic

Drupal AI-ի ռեսուրսներ

• Drupal AI

• Schema.org Blueprints մոդուլ

   

Բջջային ավտոմատների ռեսուրսներ

• Քոնվեյի «Կյանքի խաղի» բառարան - մոտ 1500 պատկեր
• Աշխատող Թյուրինգի մեքենա «Կյանքի խաղում»
• Լենգթոնի օղակներ - Վիքիպեդիա
• Բջջային ավտոմատների կանոնների հավաքածուներ
• Գիտության նոր տեսակ՝ առցանց - Սթիվեն Վոլֆրամ
• Բջջային ավտոմատներ - Nature of Code

Ուսումնասիրվել են գաղափարներ հաշվողական տեսության, դիզայն-համակարգերի, արհեստական բանականության և վեբ մշակման խաչմերուկում։

 Արտահայտված տեսակետները ենթադրական ուսումնասիրություններ են նոր միտումների շուրջ և ոչ թե որևէ ապագայի վստահ կանխատեսումներ։

Ես տեսնում եմ, որ մենք ստեղծում ենք AI գործակալներ, որոնք աշխատում են ցիկլով և փոխազդում են այլ AI գործակալների հետ լրացուցիչ ցիկլերում։

Դիզայնը կոդն է, երբ համակարգը գործում է ցիկլով՝ կյանքի ցիկլի նման, ընտրված կտավի և կանոնների հավաքածուի շրջանակում։