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

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

Автоматизацијата следи скрипта; агентите следат цел

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

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

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

Почнете со работни текови што го наградуваат контекстот

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

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

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

Дизајнирајте за ограничена автономија

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

Дефинирајте ја целта и условите за запирање

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

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

Дајте им на алатките најмала потребна привилегија

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

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

Направете секое дејство разбирливо

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

Контекстот е вистинскиот предизвик на интеграцијата

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

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

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

Проверката е местото каде што занаетот останува видлив

Генерираниот код е само хипотеза сè додека не биде прегледан и тестиран. Тоа е точно без разлика дали доаѓа од агент, колега или доцноноќен налет на човечка самодоверба.

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

npm test -- --runInBand
git diff --check
git diff

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

Мерете исходи, а не импресивни демонстрации

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

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

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

Трајната предност е подобра проценка

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

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

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