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

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

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

Почнете со работа што има јасна граница

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

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

Други добри почетни точки вклучуваат:

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

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

Осмислете го агентот како работен тек, а не како личност

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

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

Дајте му цел на секое дејство

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

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

Едноставен образец за извршување често е доволен:

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

Важниот збор е „предложен“. Агентот може да биде одлучен во рутинската работа без да стане автономен во секоја ситуација.

Направете го контекстот веродостоен пред да го направите голем

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

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

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

Одвојте ги фактите од препораките

Корисен агент треба да разликува што забележал од тоа што предлага. „Логот од распоредувањето покажува неуспешна здравствена проверка“ е тврдење за доказ. „Врати го распоредувањето назад“ е препорака што зависи од контекстот, влијанието и политиката.

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

Вградете го човечкиот преглед во патеката, а не околу неа

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

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

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

Мерете го квалитетот надвор од заштеденото време

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

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

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

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

Поумните тимови ја задржуваат својата расудливост

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

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