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

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

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

АИ не работи само врз основа на интуиција

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

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

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

Почнете со договори, не со поттикнувања

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

За API, тоа значи стабилни имиња на ресурси, документирани барања за автентикација, добро дефинирани облици на барања и одговори и корисни одговори при неуспех. Грешка како invalid request го принудува агентот да погодува. Грешка што го идентификува одбиеното поле, очекуваниот формат и релевантното ограничување му дава пат до опоравување.

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

Направете ја оперативната намера експлицитна

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

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

Овие практики не го прават системот здодевен. Тие го прават доволно сигурен за да му се довери работа.

Дизајнирајте за пронаоѓање, не за енциклопедии

На АИ-агентот не му е потребен илјадастраничен архитектонски документ во секој разговор. Му треба брзо да ја најде точната вистина. Документацијата треба да биде структурирана според одлуките и дејствата што луѓето навистина ги преземаат.

Корисен водич за услуга, на пример, може да одговори на компактен сет прашања: За кој проблем е одговорна оваа услуга? Кои зависности се критични? Како се извршува локално? Со какви податоци работи? Кои се очекуваните начини на неуспех? Кои контролни табли, предупредувања и оперативни прирачници се применуваат?

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

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

Набљудливоста станува интерфејс за расудување

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

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

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

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

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

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

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

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

Изградете стек за кој луѓето ќе ви бидат благодарни

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

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

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