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

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

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

Почнете со инженерско триење, а не со ентузијазам за ВИ

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

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

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

Дајте им на агентите улоги со јасни граници

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

Корисна дефиниција на улога вклучува четири работи:

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

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

Натерајте го агентот да ја покаже својата работа

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

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

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

Користете планови како контролна површина

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

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

Поврзувајте ги алатките внимателно

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

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

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

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

Ако задолжителна проверка не може да се заврши:
1. Наведете која проверка не успеа и зошто.
2. Зачувајте ги сите делумни докази.
3. Не тврдетe дека е завршено.
4. Ескалирајте со следното безбедно дејство.

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

Одржувајте ги луѓето фокусирани на проценката

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

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

Тимовите исто така треба да се спротивстават на мерењето успех само според обемот на излезот. Повеќе pull request-и, генерирани тестови или автоматизирани коментари не се сами по себе напредок. Подобри сигнали вклучуваат пократко време за разбирање инцидент, помалку повторливи предавања, побрзи повратни информации за ризични промени и појасни докази во точките на одлучување.

Изградете циклус на учење околу реалните исходи

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

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

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