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

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

Што го прави агентот со вештачка интелигенција поинаков?

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

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

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

Каде агентите веќе се вклопуваат во софтверската работа

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

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

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

Дајте им на агентите тесна задача пред да им дадете широк пристап

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

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

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

Дефинирајте го оперативниот договор

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

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

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

Вградете го прегледот во работниот тек, а не дополнително

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

Цел: додади валидација за незадолжително конфигурациско поле

Излез од агентот:
- Изменети датотеки: config/schema.ts, config/schema.test.ts
- Намерено однесување: отфрли вредности што не се стрингови кога полето е присутно
- Потврда: постојните тестови за шемата поминуваат; додадени се случаи за null и вредности од тип number
- Отворено прашање: празните стрингови остануваат прифатени бидејќи тековната шема ги прифаќа

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

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

Очекувајте режими на неуспех што изгледаат уверливо

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

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

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

Мерете го работниот тек, а не спектаклот

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

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

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

На партнерот сè уште му е потребен технички лидер

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

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