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

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

Агентите ја менуваат единицата на автоматизација

Традиционалната автоматизација обично е детерминистичка. Процесот за изградба компајлира познат проект. Скрипта ги ротира дневниците според фиксни правила. Овие системи се моќни токму затоа што нивните влезови и исходи се ограничени.

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

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

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

Најдобрите почетни случаи на употреба се тесни и набљудливи

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

Подобрата почетна точка има јасна граница, ограничен сет алатки и набљудлив резултат. Добри кандидати вклучуваат:

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

Секој исход може да се провери. Одржувачот може да процени дали резимето на задачата е точно. Рецензентот може да потврди дали тестот го одразува договорот. Дежурниот инженер може да одлучи дали предложениот прирачник е релевантен. Потврдата не е непријатност околу работата на агентот; таа е барањето за производот што ја прави работата на агентот употреблива.

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

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

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

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

Практична скала за одобрување

Едноставен оперативен модел е да се зголемува автономијата само откако претходното ниво е сигурно.

1. Набљудувај: читај одобрени извори и создавај резимеа, класификации или препораки.
2. Подготви: создавај нацрти, како што се закрпи, планови за тестирање, белешки за инциденти или предлози за промени.
3. Дејствувај со одобрување: изврши ограничено дејство само откако лице ќе го прегледа планираниот ефект.
4. Дејствувај автоматски: автоматизирај дејства со низок ризик и можност за враќање, со евиденција, ограничувања и јасен пат за враќање назад.

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

Генерирањето код и понатаму бара инженерска дисциплина

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

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

Агентите често се најсилни кога работниот тек ги прави овие проверки изречни. Побарајте предложен дизајн пред закрпа. Барајте тестови што ги покриваат очекуваните патеки на неуспех. Извршете статички проверки и релевантниот пакет тестови. Нека агентот објасни кои претпоставки ги направил и нека ги наведе областите што не можел да ги потврди. Последниот чекор е вреден бидејќи самоуверената проза инаку може да ја скрие неизвесноста.

Goal: add a bounded change
Constraints: do not modify deployment configuration
Required checks: unit tests, linting, error-path review
Output: patch summary, assumptions, test results, open risks

Ова не е магична формулација на поттик. Тоа е компактен договор. Јасните ограничувања им олеснуваат и на агентот и на рецензентот да препознаат кога задачата отстапила од насоката.

Оценувањето треба да се случи пред да се зголеми ентузијазмот

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

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

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

Трајната промена е кон подобро дизајнирана работа

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

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

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