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

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

Гледајте на агентот како на учесник, а не како на пророчиште

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

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

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

Каде агентите го подобруваат процесот на дизајн

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

Претворање на барањата во прашања

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

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

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

Истражување на алтернативи за дизајн

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

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

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

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

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

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

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

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

Практичен работен тек би можел да изгледа вака:

1. Програмер доставува тикет, релевантни белешки за дизајн и избран контекст од складиштето.
2. Агентот создава список со ризици во барањата и предложен план за тестирање.
3. Човекот го потврдува опсегот и го коригира недостасувачкиот контекст.
4. Агентот подготвува чекори за имплементација или промена во кодот во изолирана средина.
5. Се извршуваат автоматизирани проверки, а агентот ги пријавува нивните резултати без да крие неуспеси.
6. Рецензентот ги носи конечните одлуки за спојување, распоредување и враќање назад.

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

Заштитните механизми се дел од производот

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

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

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

Мерете ја корисноста, не новитетот

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

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

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

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

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