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

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

Сопственоста започнува каде што завршува нацртот

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

Главното прашање не е: „Дали моделот произведе код?“ Туку: „Кој може со сигурност да одговара за овој код?“ Тимот поседува промена кога може да ги опише нејзината намера, ограничувања, начини на откажување, оперативни сигнали и патека за враќање назад.

Ова е особено важно кај работни текови во стил на агенти. Агент што може да прегледа складиште, да предложи измени, да изврши тестови и да отвори pull request може да го скрати патот од барање до имплементација. Сепак, секоја дополнителна способност ја зголемува важноста на границите. На побрз соработник сè уште му треба јасна задача, ограничени овластувања и преглед соодветен на ризикот.

Дајте му на ВИ-работата добро дефиниран договор

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

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

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

Прегледувајте го однесувањето, не само синтаксата

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

Следете ја неповолната патека

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

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

Читајте ја разликата во контекст

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

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

Дизајнирајте системи што го зачувуваат расудувањето

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

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

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

Изградете циклус на сопственост

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

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

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

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