Софтверската архитектура порано се гледаше како мала група луѓе што носат големи одлуки: да ги изберат границите, да ги дефинираат интерфејсите, да го заштитат системот од идно каење. Агентите со ВИ ја усложнуваат таа слика. Тие сега можат да прегледаат кодна база, да проследат зависности, да изготват планови за миграција, да генерираат тестови и да координираат рутинска работа низ алатки. Интересното прашање веќе не е дали агент може да напише функција. Туку дали може да стане сигурен учесник во инженерски тим.

Таа промена е важна затоа што архитектурата не е првенствено вежба за цртање дијаграми. Таа е тековна практика на правење на компромисите видливи, зачувување на намерата и помагање на многу придонесувачи да менуваат систем без да го расипат. Агент што произведува изолиран код може да биде корисен. Агент што ги разбира тимските конвенции, ограничувањата за испорака, границите на сопственост и очекувањата за преглед може да биде многу повреден.

Од користење алатки до учество во тим

Конвенционалниот асистент за кодирање со ВИ често се користи како забрзан пребарувач: побарај објаснување, залепи исечок, прифати или отфрли предлог. Архитектонскиот агент работи во поширок циклус. Тој собира контекст, предлага насока на дејствување, прави ограничени промени, ги валидира и остава разбирлив запис за луѓето.

Тоа не го прави замена за софтверски архитект или технички лидер. Архитектурата вклучува одговорност, проценка за производот, безбедносна проценка и способност да се разрешат несогласувања меѓу луѓе со различни поттици. Тие одговорности остануваат човечки. Она што агентите можат да го направат е да го намалат механичкиот напор околу архитектонската работа, за луѓето да можат да поминуваат повеќе време на одлуките што навистина бараат расудување.

Каде агентите можат да им помогнат на архитектите денес

Најдобрите примени обично се конкретни, повторливи и поврзани со постоечки инженерски работен тек. Замислете тим што се подготвува да подели тесно поврзана услуга. Пред некој да ја напише миграцијата, агент може да ги мапира увозите, да го лоцира пристапот до базата на податоци, да ги идентификува потрошувачите на API и да ја сумира покриеноста со тестови околу засегнатиот модул. Резултатот не е самата одлука; тој е побрза, поцелосна почетна точка за дискусијата за дизајнот.

Агентите се особено корисни во неколку улоги за архитектонска поддршка:

• Извидување на кодната база. Тие можат да следат патеки на повици, да идентификуваат дупликат имплементации и да состават попис на модули засегнати од предложена промена.
• Подготовка на документи за дизајн. Со јасни ограничувања, тие можат белешките да ги претворат во алтернативи, да наведат претпоставки и да истакнат прашања на кои сè уште им треба сопственик.
• Планирање на миграции. Тие можат да поделат промена на повратни чекори, да идентификуваат слоеви за компатибилност и да предложат точки за валидација меѓу изданија.
• Преглед со почитување политики. Кога им се дадени тимски правила, тие можат да означат промени што ги прекршуваат конвенциите за слоевитост, именување, зависности или ракување со податоци.
• Оперативно спроведување. Тие можат да помогнат да се поврзе одлуката за дизајн со тестови, контролни листи за издание, прирачници за работа и верификација по распоредувањето.

Заедничката нишка е контекстот. Способен модел без пристап до релевантните конвенции на складиштето, архитектонските записи и работниот тек за испорака сепак ќе произведува веродостојни, но несигурни совети. Затоа добрата интеграција е поважна од умешното формулирање на барања.

Дајте му на агентот ограничена улога

„Подобри ја архитектурата“ не е применлива задача ниту за човек ниту за агент. Таа крие неодговорени прашања: подобри за цена, латентност, сигурност, брзина на развивачите, безбедност или флексибилност на производот? На продуктивен агент му треба повелба што е доволно тесна за да може да се провери.

На пример, тим може да ја дефинира улогата на агентот вака: анализирај ги предложените промени во доменот за наплата, наведи ги засегнатите граници, потврди дека е зачувана компатибилноста на јавниот API и подготви резиме за pull request. Тој опсег е значаен, но не го овластува агентот да ги редизајнира правилата за цени, да одобри издание или да менува продукциски податоци.

Направете ги ограничувањата експлицитни

Агентите треба да ги добијат истите практични ограничувања што би му биле потребни на нов член на тимот: поддржани околини за извршување, сопственост на модули, команди за тестирање, фази на распоредување, класификации на податоци и правила за надворешни зависности. Исто така, треба да знаат што не смеат да прават.

• Не спојувајте или распоредувајте без именуван чекор за човечко одобрување.
• Не менувајте тајни, ингеренции или продукциски податоци.
• Не третирајте непотврдена претпоставка како потврден архитектонски факт.
• Не правете опсежни рефакторирања кога бараната промена може да се изолира.
• Ескалирајте кога барањата се во конфликт или кога промената преминува граница на сопственост.

Ова не се знаци на недоверба. Тоа е оперативниот модел што ја прави делегираната работа безбедна. Истиот принцип важи и за луѓето: овластувањето треба да одговара на докажаниот контекст и повратноста на дејството.

Дизајнирајте ги предавањата, не само барањата

Тимската интеграција почнува таму каде што запираат многу експерименти со агенти: при предавањето. Работата на агентот треба да пристигне во форма што му овозможува на прегледувачот брзо да разбере што се променило, зошто се променило, кои докази го поддржуваат тоа и што останува неизвесно.

Корисен предлог за промена може да ги вклучува засегнатите компоненти, предвидената инваријанта, предложениот редослед на имплементација, тестовите што треба да се извршат, размислувањата за враќање назад и отворените прашања. Таа структура спречува угладен наратив да прикрие празнини во расудувањето.

Цел: Додајте нов давател на плаќања без да го промените постојното однесување при наплата.

Ограничувања:
- Зачувајте го тековниот јавен договор за наплата.
- Чувајте ја логиката специфична за давателот зад граница на адаптер.
- Додајте тестови за патеки на успех, истекување на време и грешка од давателот.
- Не менувајте ја конфигурацијата за распоредување.

Потребно предавање:
- Засегнати датотеки и интерфејси
- Претпоставки и неразрешени прашања
- Извршена валидација
- Патека за враќање назад или оневозможување

Овој вид краток опис е повреден од долгo барање бидејќи воспоставува заеднички договор. Тој создава и трага за ревизија. Кога агентот греши, тимот може да види дали неуспехот произлегол од недостиг на контекст, нејасно ограничување, недоволна валидација или несоодветно ниво на автономија.

Валидацијата е архитектонската контролна рамнина

Генерираниот код може да изгледа кохерентно додека прекршува скриена инваријанта. Затоа резултатот на агентот треба да помине низ истите контроли што ги штитат промените напишани од луѓе: тестови, статичка анализа, проверки на зависности, преглед на код, фазно распоредување и набљудливост по изданието.

За архитектонски промени, валидацијата треба да се прошири надвор од тоа дали изградбата поминува. Прашајте дали новата насока на зависност е намерна, дали е дефинирано однесувањето при неуспех, дали повторните обиди можат да создадат дупликат нуспојави и дали верзионираните интерфејси можат да коегзистираат за време на пуштање во употреба. Агентот може да помогне во набројувањето на овие проверки, но тимот мора да одлучи кои од нив се задолжителни.

Повратноста е особено важна. Претпочитајте знаменца за функции, адаптери за компатибилност, мали миграции и мерливи фази на пуштање во употреба наместо една голема трансформација. Агентите се ефикасни во брзо создавање многу промени; тоа го прави уште поважно ограничувањето на радиусот на влијание на секоја промена.

Мерете го квалитетот на соработката, не обемот на резултатите

Генерираните линии, затворените тикети и отворените pull requests се слаби мерки за успех. Здравата интеграција на агент треба да го намали времето поминато во наоѓање контекст, да ги направи прегледите појасни, да открие повеќе проблеми пред продукција и да ја остави кодната база полесна за менување. Ако само го зголемува бројот на промени што чекаат преглед, таа ја преместила работата наместо да ја отстрани.

Почнете со еден работен тек каде што влезот, очекуваниот излез и прегледувачот се јасни. Набљудувајте каде на агентот му е потребна корекција. Подобрете ги контекстот и заштитните ограничувања пред да ги проширите неговите дозволи. Со текот на времето, тимот може да открие дека најкорисните агенти не се оние што пишуваат најмногу код, туку оние што ги одржуваат поврзани одлуките, интерфејсите и оперативните детали.

Улогата на архитектот станува повредна

Агентите со ВИ можат да ја забрзаат архитектонската работа, но исто така ја прават архитектонската дисциплина понеопходна. Кога промената станува евтина, и лошо обликуваната промена станува евтина. Трајната предност им припаѓа на тимовите што можат јасно да ги наведат своите ограничувања, да ја зачуваат сопственоста, постојано да валидираат и да ги научат агентите како навистина се работи.

Иднината не е автономен архитект што заменува тим. Таа е добро интегриран агент што му помага на тимот да види повеќе од својот систем, повнимателно да расудува за промената и да дејствува со поголема доследност. Тоа е потивко ветување од возбуда околу автоматизацијата, но е она што најверојатно ќе го подобри софтверот на долг рок.