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

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

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

Од довршување до контролирано извршување

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

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

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

Архитектурата станува дел од поттикот

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

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

Дајте им на агентите мапа, а не лавиринт

Агентите работат подобро кога кодната база евтино одговара на вообичаени прашања. Каде е јавниот API? Која команда ја извршува тест-пакетот? Кој пакет е одговорен за автентикација? Како се создаваат миграции на базата на податоци? Што е забрането во продукцискиот код?

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

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

Конкретен работен тек за промена со големина погодна за агент

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

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

Цел: Запиши ревизорски настан кога администратор оневозможува сметка.

Ограничувања:
- Зачувај го постојниот API одговор.
- Вклучи ID на актерот, ID на целната сметка, причина и временска ознака од серверот.
- Исклучи ингеренции, токени и тела на барања.
- Повторно искористи ја воспоставената апстракција за ревизорски настани, ако постои.
- Додади или ажурирај фокусирани тестови.
- Изврши ја релевантната тест-команда и пријави неуспеси без да ги прикриваш.

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

Прегледајте ги доказите, не само разликата

Уредна разлика сè уште може да биде погрешна. Промените создадени од агент заслужуваат ист инженерски преглед како и промените создадени од луѓе, со малку дополнително внимание на тоа како е донесен заклучокот.

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

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

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

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

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

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

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

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

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

Улогата на развивачот станува попромислена

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

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