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

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

Од одговор на промпт до работен циклус

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

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

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

Со што реално може да се справи развоен тим со ВИ

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

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

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

Почнете со улоги, не со рој

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

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

Практичен договор за задача

Пред агентот да дејствува, воспоставете го договорот на јасен јазик:

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

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

Градете системи околу верификацијата

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

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

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

Задача: Додај валидација за дупликат адреси на е-пошта при ажурирање на профилот.

Дозволено:
- Измени го кодот на апликацијата и единечните тестови.
- Изврши го постоечкиот пакет единечни тестови.

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

Запри и ескалирај:
- Ако е потребна миграција на базата на податоци.
- Ако постоечкото правило за единственост е нејасно.
- Ако тестовите бараат недостапни ингеренции.

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

Дизајнот на дозволите е дизајн на производ

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

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

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

Човечката улога станува повредна, не помалку вредна

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

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

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

Вашиот прв агент треба да заслужи доверба

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

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

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