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

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

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

Од завршување задачи кон составување системи

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

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

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

Изберете работни текови пред да изберете личности

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

Добри почетни кандидати

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

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

Дајте им договор на агентите, а не нејасно барање

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

Цел: Врати го пакетот unit-тестови за модулот за плаќања.

Опсег: Измени само датотеки под services/payments.
Дозволени дејства: Читај датотеки од складиштето, уредувај датотеки во опсегот, изврши ја документираната команда за unit-тестови.
Не: Менувај конфигурација за распоредување, тајни, шеми на бази на податоци или договори за јавен API.
Успех: Релевантните тестови поминуваат и промената вклучува концизно објаснување.
Ескалирај кога: Неуспехот укажува на промена на меѓууслужен договор или недостасувачки ингеренции.

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

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

Контекстот е инженерски ресурс

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

Затоа, подобрувањето на контекстот е инвестиција со голем ефект. Одржувајте ги тековни одговорностите за услугите. Ставете ги упатствата за локален развој и валидација блиску до кодот. Бележете ги архитектонските одлуки во концизна, пребарлива форма. Направете ги интерфејсите експлицитни. Овие навики ја подобруваат и човечката соработка; агентите само откриваат каде е слабиот синџирот на снабдување со информации.

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

Градете доверба преку докази и заштитни ограничувања

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

• Користете ингеренции со најмали привилегии и одвојте ги дејствата само за читање од дејствата што можат да запишуваат.
• Барајте преглед за промени во кодот, промени на дозволи, надворешна комуникација и дејства што влијаат врз продукцијата.
• Направете ги дејствата набљудливи преку дневници, diff-ови, излез од команди и врски до користените артефакти.
• Дефинирајте буџети за време, трошок, повторни обиди и бројот на датотеки или системи врз кои агентот може да влијае.
• Обезбедете јасен механизам за запирање и пат за човечка ескалација.

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

Редизајнирајте ја соработката, а не само индивидуалната продуктивност

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

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

Предноста на композиторот

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

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