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

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

Сопственоста се преместува од притискањата на тастатурата кон исходите

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

Тоа ја менува практичната дефиниција на сопственоста. Највредното прашање повеќе не е едноставно: „Кој го напиша овој код?“ Станува: „Кој ги дефинираше целта, ограничувањата, критериумите за прифаќање и процесот на верификација што ја направија оваа промена доверлива?“

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

Во што агентите навистина се добри

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

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

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

На агентите им требаат оперативни граници, а не нејасна доверба

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

Дајте му на агентот тесен мандат

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

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

Направете ја верификацијата дел од задачата

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

npm test
npm run lint
npm run typecheck

Овие команди имаат значење само кога припаѓаат на документираниот работен тек на проектот. Начелото е универзално: тврденото завршување од агентот треба да биде поврзано со набљудливи резултати, а не со угладено резиме.

Одделете го читањето од дејствувањето

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

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

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

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

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

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

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

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

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

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

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

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