На повеќето софтверски тимови не им се потребни ВИ агенти за да пишуваат повеќе код. Им се потребни за да ја отстранат работата што ги спречува искусните луѓе да размислуваат јасно.

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

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

Извршувањето не е исто што и инженерството

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

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

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

Дајте им на агентите ограничени, проверливи задачи

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

Корисната задача за агент често има четири делови:

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

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

Пример: претворете извештај за грешка во пакет за истрага

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

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

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

Изградете работен тек, не ритуал со чет-бот

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

На пример, агент што изготвува pull request-и за ажурирање зависности може да ја следи оваа низа:

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

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

Направете ја потврдата дел од договорот

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

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

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

Зачувајте го човечкото внимание за избори со големо влијание

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

Пред да делегира имплементација, техничкиот лидер може да праша:

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

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

Почнете со влијание со низок ризик

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

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

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

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

Најдобриот исход не е тим што работи без луѓе. Тоа е тим во кој луѓето поминуваат помалку време претворајќи очигледна работа во притискања на тастери и повеќе време подобрувајќи ги одлуките на системот.

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