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

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

Вашиот систем веќе содржи наставна програма

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

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

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

Почнете со логиката што ги менува одлуките

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

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

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

Направете го контекстот достапен за преземање, ограничен по опфат и актуелен

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

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

Користете слоевит модел на контекст

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

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

Задача: Додади "paused" состојба на претплата.

Секогаш примени:
- Премините меѓу состојби се валидираат во доменската услуга.
- Секој премин емитува ревизорски настан.
- Надворешните повици за наплата мора да бидат идемпотентни.

Преземи за оваа задача:
- Дефиниции на состојби на претплата
- Тестови за премини
- Интерфејс на адаптерот за наплата
- Шема на ревизорски настан
- Договор за API барање и одговор

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

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

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

Добрите примери треба да го изложуваат расудувањето во точките на одлучување. Разгледајте API мутација што активира надолна операција. Корисната лекција не е само дека кодот враќа 202; туку дека барањето се прифаќа асинхроно, се создава трајна задача пред одговорот и дупликат-барањата се разрешуваат безбедно. Тоа е системска логика и токму таква логика ВИ треба да зачува.

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

Дизајнирајте за верификација, не за слепо генерирање

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

Здрав циклус на преглед може да го вклучува следново:

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

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

Држете ги пристапот и овластувањето одвоени

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

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

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

Трајната предност е појасно инженерство

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

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