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

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

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

Сопственоста е повеќе од авторство

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

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

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

Каде агентите можат да преземат значајна сопственост

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

• Истражување на репозиториумот: следење feature flag, идентификување дупликат-имплементации, мапирање места на повик или резимирање зависности на модул.
• Механички промени: преименување на конфигурациско поле, применување позната API миграција, генерирање тест-случаи според воспоставен образец или ажурирање документација заедно со кодот.
• Тријажа на неуспеси: собирање релевантни логови, групирање поврзани неуспеси на тестови, споредување регресија со неодамнешен diff и предлагање хипотези.
• Рутинска оперативна работа: подготвување контролна листа за враќање назад, проверка на конзистентноста на конфигурацијата или изработка на план за промена за човечко одобрување.

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

Скриената цена на работата што изгледа автономна

Агентот може да создаде впечаток на напредок побрзо отколку што човек може да го прегледа. Тоа е и неговата привлечност и неговиот ризик. Голема закрпа што се компајлира не е нужно точна закрпа. Тест-пакет што поминува не е доказ дека промената почитува недокументиран договор. А добро напишан опис на pull request може да сокрие слабо расудување исто толку лесно колку што може да разјасни силно расудување.

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

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

Прегледувајте го расудувањето, не само diff-от

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

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

Човечката сопственост станува поархитектонска

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

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

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

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

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

1. Дефинирајте ја границата на задачата. Наведете што агентот смее да промени, што не смее да промени и кој исход се смета за завршен.
2. Обезбедете му безбедна средина. Користете ограничени акредитиви, изолирани тест-ресурси, заштитени гранки и промени што може да се прегледаат.
3. Барајте верификација. Побарајте од агентот да ги изврши релевантните проверки таму каде што се достапни и да пријави неуспеси наместо тивко да ги заобиколи.
4. Чувајте ја надлежноста за распоредување одделена. Генерирањето закрпа и нејзиното објавување треба да бидат различни дозволи, особено за системи насочени кон клиенти или регулирани системи.
5. Учете од пропустите. Кога агентот ќе направи лоша претпоставка, подобрете ги тестовите, документацијата, заштитните мерки или шаблонот на задачата наместо само да ја обвинувате алатката.

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

На кодот сè уште ќе му требаат чувари

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

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