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

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

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

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

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

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

Каде агентите создаваат вистинска предност

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

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

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

Добриот дизајн на агент започнува со граници

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

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

Дајте им на агентите алатки, не неограничена слобода

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

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

Проверката е центарот на работниот тек

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

Практичен циклус на имплементација изгледа вака:

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

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

Инженерската улога станува повеќе уредничка

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

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

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

Воведувајте агенти без да ја изгубите суштината

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

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

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