Повеќето неуспеси на ВИ во софтверската работа не се неуспеси на промптови. Тие се неуспеси на контекстот.

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

Корисното прашање не е: „Каков промпт треба да ѝ дадеме на ВИ?“ Туку: „Каков контекст му е потребен на овој систем за да донесе безбедна одлука?“

Промптовите ја опишуваат намерата; контекстот ја дефинира реалноста

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

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

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

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

Дајте ѝ на ВИ ограничен работен сет

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

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

Почнете со договорот

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

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

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

Контекстот треба да пристигнува во слоеви

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

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

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

Алатките помагаат само кога границите се јасни

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

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

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

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

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

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

ВИ може да ја забрза имплементацијата и да открие превидени гранки. Не може да ја отстрани потребата од одговорност за резултатот. Лицето или тимот што ја испорачува промената останува одговорен да одлучи што значи „точно“ во околниот систем.

Градете го контекстот како способност на производот

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

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

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