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

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

Сметајте ги агентите за системи, а не за магија

Ефективниот агент не е едноставно „моќен модел со prompt“. Тој е мал софтверски систем со влезови, ограничувања, алатки, состојба, верификација и јасна одговорност. Моделот обезбедува проценка врз основа на јазик и нецелосни информации; околниот систем ја обезбедува доверливоста.

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

Овој принцип на дизајн е едноставен: дајте им на агентите доволно овластување за корисен напредок, но не доволно овластување за да создадат скапо изненадување.

Почнете таму каде што повратната информација е брза

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

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

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

Дефинирајте го договорот за задачата пред prompt-от

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

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

Цел: Поправете ја грешката при валидација опишана во проблемот.

Дозволен опсег:
- Датотеки под src/validation/
- Поврзани тестови под tests/validation/

Задолжителна верификација:
- Извршете: npm test -- validation
- Пријавете неуспеси без да се обидувате со неповрзани поправки

Ескалирајте кога:
- Поправката бара миграција на база на податоци
- Однесувањето на јавниот API е нејасно
- Се чини дека се неопходни повеќе од три датотеки надвор од дозволениот опсег

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

Вградете верификација во работниот тек

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

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

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

Усогласете ја автономијата со цената на грешката

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

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

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

Мерете ја работата, а не спектаклот

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

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

Трајната предност е подобра инженерска практика

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

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