На повеќето софтверски тимови не им е потребна уште една ВИ-функција што извршува задача по команда. Им се потребни системи што можат да научат како работата навистина се извршува.

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

Дизајнирањето корисна ВИ за софтверска работа значи да се надмине пристапот „кажи ѝ што да прави“ и да се премине кон „помогни ѝ да разбере како работи оваа организација, а потоа дај ѝ ограничени начини да придонесува“.

Извршувањето е лескиот дел

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

Ограничувањата се појавуваат кога исправноста зависи од информации надвор од промптот. Дали нов API треба да враќа објект за грешка или да фрли исклучок? Дали ова складиште користи рендерирање на серверска страна? Кои полиња е безбедно да се евидентираат? Дали миграцијата треба да поддржи постепено пуштање во употреба? Дали „мала“ UI-промена е опфатена со договор за пристапност?

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

Што значи ВИ-системот да учи

Учењето не мора да значи повторно обучување модел при секој commit. Во практичните софтверски системи, тоа обично значи давање контролиран пристап на ВИ до траен контекст и повратни информации.

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

Клучното дизајнерско прашање не е: „Може ли моделот да види сè?“ Туку: „Кои информации му помагаат да донесе подобра одлука за оваа задача и како можеме да ја потврдиме таа одлука?“

Контекстот треба да биде структуриран, а не само истурен

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

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

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

Раздвојувањето на овие слоеви олеснува да се утврди зошто ВИ дала препорака и да се ажурира системот кога ќе се промени некоја конвенција.

Претворете ги повратните информации во подобро идно однесување

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

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

На пример, од агент што предлага промена во кодот може да се бара да изработи краток план пред уредувањето:

Goal: add a validation rule for account names
Affected area: account creation API
Constraints: preserve existing error response format
Verification: unit tests, API contract tests, static analysis
Rollback: remove the validation path behind the feature flag

Планот не е бирократија. Тој му дава на прегледувачот нешто конкретно што може да го оспори пред да се направи голема промена. Исто така, рано го открива недостигот од контекст: можеби нема feature flag или API-договорот не е документиран.

Дајте им на агентите овластување пропорционално на повратливоста

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

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

1. Читање и објаснување информации.
2. Подготвување артефакти за човечки преглед.
3. Правење промени во изолирана гранка или sandbox.
4. Извршување ограничени чекори за верификација.
5. Извршување повратливи дејства со изречни проверки на политики.
6. Ескалирање неповратливи или дејства со големо влијание до одговорно лице.

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

Дизајнирајте за несогласување, а не само за успех

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

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

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

Трајната предност е организациското учење

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

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

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