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

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

Можноста е реална, но реална е и инженерската работа потребна за безбедно користење агенти. Корисното прашање не е: „Може ли ВИ да го напише овој код?“ Туку: „Кој дел од одговорноста можеме да го делегираме, под какви контроли и како ќе го потврдиме резултатот?“

Од предлози до ограничена одговорност

Дополнувањето код и понатаму е вредно. Го намалува триењето во позната работа: пополнување тест-случај, преведување структура на податоци или потсетување на образец од библиотека. Но, сè уште го остава развивачот одговорен за поставување на проблемот во контекст, проверување претпоставки и поврзување на деловите.

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

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

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

Границата е одлика, а не ограничување. Јасната граница го прави агентот полесен за оценување, побезбеден за извршување и поедноставен за подобрување.

Дајте им на агентите задача, а не нејасна желба

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

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

Цел: Врати го постојното однесување на одговорот на крајната точка за ресетирање лозинка.

Опфат: Измени ги само API услугата и нејзините тестови.
Ограничувања: Не менувај ја шемата на базата на податоци или јавните полиња на одговорот.
Потврда: Изврши го насочениот пакет тестови и пријави го резултатот.
Ескалирај ако: Причината изгледа дека ја вклучува конфигурацијата на давателот на идентитет.

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

Направете го „завршено“ набљудливо

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

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

Изградете скала на доверба

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

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

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

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

Пристапот до алатки е вистинската граница на способностите

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

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

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

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

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

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

• што променил и зошто;
• што прегледал или на што се потпрел;
• кои проверки поминале, не успеале или не можеле да се извршат;
• кои ризици или алтернативи остануваат.

Ова го забрзува прегледот без да се преправа дека резимето е доказ. Доказот останува во кодот, тестовите, околината и набљудливото однесување.

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

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

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

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

Одговорноста се заслужува преку ограничувања

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

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