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

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

Од автоматско довршување до одговорни работни текови

Довршувањето код е реактивно: развивачот пишува, моделот предлага. Агентскиот работен тек е попромислен. Со задача како „подготви ја оваа услуга за ново API поле“, агентот може да го испита релевантниот код, да ги проследи патеките за валидација и серијализација, да предложи измени, да изврши насочени тестови и да ја сумира преостанатата неизвесност.

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

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

Работата на развивачот станува појасна, не помала

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

Придонесот на искусен развивач сè повеќе вклучува дизајнирање на работата околу самата работа:

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

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

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

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

Практичен пример: мала промена во API

Разгледајте барање за додавање незадолжително поле preferredName во API за клиенти. Пристап ориентиран кон задача може да произведе закрпа во една класа на модел и да запре. Стратешкиот работен тек поставува пошироки прашања: Дали полето се прифаќа при запишување? Дали се враќа при читање? Дали валидацијата дозволува празни вредности? Дали на шемата на базата на податоци ѝ е потребна миграција? Дали се засегнати генерираните клиенти? Кои постојни тестови го утврдуваат очекуваното однесување?

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

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

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

Пристапот до алатки е местото каде што почнува вистинскиот ризик

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

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

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

Мерете исходи, не активност на агентите

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

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

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

Стратегијата е трајната предност

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

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