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

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

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

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

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

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

Корисни шаблони за агенти за софтверски тимови

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

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

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

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

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

Корисен ментален модел е мала контролна јамка:

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

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

Цел: подготви надградба на зависност за преглед
Дозволени дејства: читај датотеки од репозиториумот, уредувај гранка, извршувај одобрени проверки
Доказ за успех: манифестот е променет, lockfile е конзистентен ако се користи, проверките се пријавени
Услов за запирање: двосмислена миграција, неуспешна потврда или недостасувачки ингеренции
Предавање: резиме на променетите датотеки, извршените команди, резултатите и отворените ризици

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

Заштитните мерки се дизајн на производ, а не бирократија

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

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

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

Направете ги важните дејства прегледливи

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

Потврдувајте со системи, не со самодоверба

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

Мерете ја работата што се променила

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

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

Вистинската промена е организациска

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

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