AI (Вештачка Интелигенција)

AI Agents: The Next Frontier in Software Development Ownership

AI агенти: Следната граница во сопственоста на развојот на софтвер

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

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

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

Од автодовршување до делегирана работа

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

Разликата е важна бидејќи главниот ризик повеќе не е само неточно генериран код. Тоа е неточно дејство во реална средина.

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

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

Сопственоста станува проблем на дизајн на системот

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

Она што се менува е синџирот на делегирање.

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

Дефинирајте ја границата пред поттикот

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

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

Оваа структура не е бирократија. Така тимот го претвора нејасниот „асистент со ВИ“ во разбирлива компонента на својот систем за испорака.

Почнете со работни текови што создаваат докази

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

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

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

Практична агентска задача има три својства:

  • Целта е доволно специфична за да се оцени.
  • Достапните алатки се ограничени на она што го бара целта.
  • Резултатот може да се прегледа преку артефакти, тестови, дневници или разлики.

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

Вградете заштитни механизми во средината

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

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

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

Направете го неуспехот исход од прв ред

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

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

Прегледувајте го расудувањето преку работниот производ

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

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

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

Трајната предност е подобро делегирање

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

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

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

Портрет на автор на блогот

Mihajlo

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