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

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

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

Деловниот контекст веќе се крие во техничките артефакти

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

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

Разликата не е само во повеќе контекст. Таа е разликата меѓу генерирање код што изгледа разумно и предлагање промена што одговара на оперативниот модел на системот.

Корисните деловни сигнали во репозиториумот често вклучуваат:

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

Ниту еден од овие артефакти не е совршен сам по себе. Заедно, тие формираат практична наставна програма за асистент со ВИ.

Дајте му на моделот ограничен пат на учење

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

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

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

Користете ја кодната база за да ги научите воспоставените правила и користете експлицитни прашања за да ги откриете правилата што сè уште не се утврдени.

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

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

Само врз основа на доставените датотеки:
1. Опиши го тековното правило за авторизација на извоз.
2. Наведи го секој услов и доказот за него.
3. Идентификувај нејаснотии или спротивставени сигнали.
4. Предложи ја најмалата промена за новото правило за сметки во пробен период.
5. Наведи тестови што треба да поминат, да не поминат или да се додадат.

Ова барање поттикнува разлика што лесно се губи при брза работа: набљудуваното однесување не е исто што и наменетата политика. Моделот може да го сумира првото; одговорен човек сè уште го потврдува второто.

Користете ги тестовите како разговор за последиците

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

it("denies trial exports until an administrator enables exports", () => {
  const account = trialAccount({ exportsEnabled: false });
  expect(canExport(account, adminUser())).toBe(false);
});

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

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

Градете пребарување околу значење, а не околу обем

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

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

Корисен редослед за избор на контекст е:

1. Најдете го доменскиот модел и јавниот договор.
2. Најдете ја точката на одлука каде што се спроведува однесувањето.
3. Најдете тестови за нормални, одбиени и патеки со грешка.
4. Најдете артефакти за трајно складирање или настани што ја ограничуваат промената.
5. Вклучете само оперативна конфигурација потребна за разбирање на однесувањето при распоредување.

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

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

Најкорисните асистенти со ВИ не се оние што секогаш звучат сигурно. Тоа се оние чиј излез ја прави проверката ефикасна.

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

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

Претворете ја секоја промена во подобар наставен материјал

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

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

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

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