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

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

Од довршување линии до довршување резултати

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

Агентот работи на поинакво ниво. Може да добие резултат како „додај запис за ревизија кога администратор ја менува улогата на корисник“ или „пронајди зошто оваа конфигурација за распоредување не успева при валидација“. За да успее, можеби ќе треба да истражи постојни обрасци, да ја идентификува релевантната граница меѓу апликацијата и инфраструктурата, да ажурира тестови и да пријави компромиси.

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

Што бара вистинската сопственост над кодот

На корисните агенти им треба повеќе од пристап до складиште и способен модел. Им треба работна средина осмислена така што правилното однесување да биде полесно од неправилното.

• Јасни граници на задачата. Добрата задача го наведува посакуваното однесување, релевантните ограничувања и тоа што не смее да се промени. „Подобри ја автентикацијата“ е нејасно; „додај ограничување на бројот на барања за ресетирање лозинка без да го менуваш успешното однесување при ресетирање“ е применливо.
• Читливи локални конвенции. Тестовите, обрасците за именување, архитектонските граници и концизната документација му даваат на агентот докази што може да ги следи. Недокументирана кодна база бара и од луѓето и од агентите да погодуваат.
• Брза верификација. Насочените тестови, линтерите, проверките на типови и повторливите локални команди го претвораат предлогот на агентот во нешто што може да се тестира. Бавната или ненадежна повратна информација го умножува ризикот.
• Пристап со најмалку привилегии. Агентот треба да ги добие само ингеренциите, околините и дозволите потребни за задачата. Пристап за читање, изолирани гранки и извршување во песочник се практични заштитни мерки, а не знаци на недоверба.
• Резултат што може да се прегледа. Агентот треба да објасни кои датотеки се сменети, кои одлуки се донесени, кои проверки се извршени и каква нерешена неизвесност постои. Разлика без образложение не е сопственост; тоа е само излез.

Агентите треба да поседуваат циклуси, не само алатки

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

Практичен пример: безбедна промена на API

Да претпоставиме дека на услуга ѝ треба ново опционално поле во одговор од API. Способен агент не треба да застане по промена на тип на одговор. Треба да ги лоцира правилата за серијализација, да ги испита практиките за верзионирање, да најде тестови на договори и да утврди дали клиентите можат безбедно да го игнорираат полето. Ако полето содржи чувствителни податоци, треба да ги идентификува импликациите за авторизација и евидентирање пред имплементацијата.

Добро ограничен работен тек би можел да изгледа вака:

1. Прочитај ги крајната точка, нејзиниот модел на одговор и блиските тестови.
2. Пребарај воспоставени конвенции за опционални полиња и компатибилност на API.
3. Имплементирај ја најмалата компатибилна промена.
4. Додај или ажурирај насочени тестови за присуство, отсуство и однесување при авторизација.
5. Изврши ги наведените команди за валидација и пријави ги нивните резултати.
6. Ескалирај ако барањето е во конфликт со постоечки договор или бара одлука за производот.

На агентот не му се верува затоа што звучи самоуверено. Му се верува затоа што неговата работа е ограничена, проверлива и проверена во однос на сопствените докази на системот.

Каде човечката одговорност останува суштинска

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

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

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

Изградете средина во која агентите можат да успеат

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

Потоа измерете го работниот тек, не само конечниот код. Дали агентот ги најде релевантните датотеки? Дали измени неповрзани области? Дали тестовите беа значајни? Дали рано ја истакна неизвесноста? Дали прегледувачот можеше брзо да ја разбере промената? Овие прашања откриваат дали системот станува посигурен.

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

Вистинската транзиција е менаџерска

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

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

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