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

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

Од автоматско довршување до работа насочена кон цел

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

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

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

Архитектонски партнер не значи замена за архитект

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

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

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

Дајте му на агентот повелба, а не нејасна амбиција

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

• Цел: Намалување на дуплираната логика за валидација во именуван модул.
• Опсег: Изменувајте само код на апликацијата и единечни тестови; не менувајте го јавното однесување на API.
• Доказ: Извршете ја релевантната команда за тестирање и пријавете го резултатот.
• Заштитни мерки: Не менувајте миграции на базата на податоци, тајни, поставки за продукција или политики за пристап.
• Ескалација: Застанете ако работата бара промена на надворешен договор или тек чувствителен на безбедност.

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

Контекстот е вистинскиот интерфејс

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

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

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

Проверката е местото каде што се заслужува довербата

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

Практичниот работен тек го раздвојува планирањето од извршувањето:

1. Побарајте од агентот да испита и да предложи план.
2. Прегледајте ги претпоставките, засегнатите области и наменетите команди.
3. Дозволете само дејства што се потребни за одобрениот опсег.
4. Барајте тестови, проверка со linting или други релевантни проверки.
5. Прегледајте ја разликата и доказите на агентот пред спојување или распоредување.

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

Дизајнирајте за неуспешни обиди

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

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

Границите на дозволите се одлуки за производот

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

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

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

Каде агентите испорачуваат вредност сега

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

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

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

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

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