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

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

На AI му се потребни разбирливи системи, не само големи контекстни прозорци

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

Разбирливост значи дека системот открива доволно структура за алатка или агент точно да одговори на основните прашања: За што е одговорна оваа услуга? Кои влезови се валидни? Кои несакани ефекти може да настанат? Како се мери успехот? Што никогаш не смее да се случи?

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

Изградете средина што агентот може безбедно да ја испита

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

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

• го пребарува складиштето и да чита релевантни датотеки;
• извршува насочени тестови и статичка анализа;
• менува датотеки во одобрен работен простор;
• создава diff за преглед;
• запре кога тестовите не успеваат или претпоставките не се разрешени.

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

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

Претворете го имплицитното знаење во достапни докази

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

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

Дизајнирајте го контекстот околу одлуката

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

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

Направете ја проверката дел од работниот тек

Работата генерирана од AI треба да се смета за предлог сè додека не се соочи со независни проверки. Најсилниот образец не е „генерирај, па верувај“, туку „генерирај, испитај, провери и забележи“.

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

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

task: update_dependency
success_conditions:
  - lockfile_changed
  - focused_tests_pass
  - vulnerability_scan_completed
stop_conditions:
  - major_version_change
  - failing_integration_test
  - license_policy_uncertain
required_output:
  - summary
  - diff
  - test_results
  - unresolved_risks

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

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

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

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

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

Користете AI за да го подобрите системот што го содржи

Најтрајната вредност често доаѓа од користењето AI за да се открие каде софтверот е тешко разбирлив. Повторените барања за истото објаснување на складиштето може да укажуваат на недостиг од архитектонска документација. Честите грешки на агентот околу работен тек може да откријат нејасен интерфејс. Обрасците на рачен преглед може да укажуваат на недостиг од автоматизирана проверка.

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

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

Вистинската промена е од одговори кон одговорно дејствување

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

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