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

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

Сопственоста на кодот е повеќе од авторство

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

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

Оваа разлика води до корисна рамка: агентите треба да станат чувари на ограничени одговорности, додека луѓето остануваат сопственици на исходите.

Од копилот до чувар

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

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

• Идентификува ажурирања во одобрен опсег на верзии.
• Создаде фокусирана гранка за секое ажурирање.
• Ги изврши постојните тестови и статички проверки на репозиториумот.
• Ги сумира изменетите белешки за издавање што му ги доставил тимот.
• Ги означи неуспесите како блокирани, наместо да нагаѓа за широко заобиколно решение.
• Подготви pull request што може да се прегледа, со јасни белешки за враќање назад.

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

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

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

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

Читајте широко, пишувајте тесно

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

Одделете ги акредитивите според околина и задача. Претпочитајте привремен, ограничен пристап. Осигурете се идентитетот на агентот да е видлив во commits, pull requests, логови и записи за распоредување. Ако дејството не може подоцна да се припише и реконструира, тоа е премногу непрозрачно за рутинска автоматизација.

Дефинирајте ја ескалацијата како функција

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

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

Градете работни текови околу докази што можат да се прегледаат

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

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

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

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

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

Зачувајте ја способноста на тимот да ги разбира сопствените системи

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

Спротивставете се на ова намерно. Одржувајте ги архитектонските одлуки концизни и ажурни. Барајте содржајни описи на pull request. Ротирајте ја одговорноста за преглед низ критичните области. Користете агенти за да објаснат патеки во кодот и да откријат недостасувачка документација, но потврдете ги тие објаснувања според изворот и луѓето одговорни за доменот.

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

Трајната предност е одговорното засилување

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

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