В EBRD AI пише кода, но Jira тикетът решава резултата

В публикувания на 3 ноември 2026 г. казус на EBRD в DEV.BG софтуерният инженер Тодор Филев започва подготовката на задачите в Jira с въпроса „Правилно ли е разделено това?“. В описания екип AI агентите пишат голяма част от кода, а инженерите оформят задачите, преглеждат заявките за промяна и решават дали резултатът изпълнява изискванията. За да възложат работа на агент, те първо трябва да запишат в тикета обхвата, вече взетите решения и проверимото поведение.

В публикацията на StackNews.ai за същата разработка са описани предложение на Copilot, основано на несъществуваща колона в базата данни, непоискани промени по съседни задачи и липса на преработка на вече написания код за конкретната функционалност. Последният резултат е наблюдение от един проект, а не измерване за всички екипи на EBRD. Казусът показва и границата на автоматизацията: правдоподобното предложение на агента става работно изискване едва след проверка и човешко решение.

Къде непълният тикет променя реализацията

Функционалността в казуса изглежда проста на ниво общ дизайн: потребителят прави избор и формата показва различни полета според него. За да се напише кодът, обаче, трябва да е ясно откъде идва всяка стойност, кой може да я редактира и какво става с вече въведеното, когато изборът се промени. Нужно е и правило за случая, в който един от източниците на данни спре да работи.

Първоначалното разделяне на задачите и общата идея за API не дават всички тези отговори. Филев използва GitHub Copilot, за да подреди технически варианти, но екипът избира кой компромис е приемлив за системите, които ще четат данните. В тази функционалност общо позната на системите стойност се пази като препратка, а собствена стойност — като текст. Решението следва потребностите на проекта; агентът може да го приложи последователно едва след като хората са го взели.

Други решения са също толкова конкретни. Когато произходът на стойност не е ясен, тя остава недостъпна за редакция; ако един източник отпадне, останалата част от формата продължава да работи. Без записани правила агентът би трябвало сам да избере поведение, което засяга потребителя и съседните системи. Така празнината в тикета се превръща в промяна на продукта.

Какво трябва да съдържа задачата за агента

Описаният екип използва постоянна структура, в която колегата, специалистът по качеството и агентът намират решенията на предвидимо място. Следният кратък шаблон събира елементите на този процес, без да предполага конкретна настройка на Jira:

• Обхват и изключения: исканата промяна и съседните поведения или задачи, които не трябва да се засягат.
• Потребителска история и зависимости: кой използва функционалността, откъде идват данните и кои други системи разчитат на тях.
• Решения и отворени въпроси: приетите бизнес правила се отделят от въпросите, по които агентът трябва да изчака човек.
• Критерии за приемане: всеки проверим случай получава отделен сценарий Given/When/Then.
• Технически бележки: насоки към съществуващия код и ограниченията на реализацията, проверени в действителната система.

За формата от казуса условен критерий би започнал така: при запазена стойност, когато потребителят смени избора, тогава формата показва полетата за новия избор. Тикетът трябва да продължи с одобреното правило за старата стойност — дали се запазва, изчиства или изисква ново потвърждение. Ако екипът още обсъжда това правило, то принадлежи при отворените въпроси, а не в свободата на агента да допише сценария.

Ясното изключение има същата тежест като ясното изискване. Ако промяна в друга задача остава извън обхвата, това трябва да е написано, защото Copilot вече е редактирал съседни тикети без искане. Разделянето на „Решено“ и „Отворено“ пази и контекста от дълъг разговор с асистента: когато част от ранните указания се изгуби, тикетът остава записът на решенията.

Проверката и одобрението спират предположенията

Филев дава на Copilot достъп само за четене до кода и данните, за да може твърденията му да се сверяват с реалната система. При предложение, което изглежда удобно, той иска конкретен източник в кода или данните. Така несъществуващата колона и правдоподобните, но измислени примерни данни не се превръщат в приети факти за задачата.

Преди редакция в Jira асистентът трябва да покаже точния списък с предлаганите промени и да получи изричното одобрение на Филев. След редакцията предишната версия на тикета се запазва за сравнение, включително за проверка дали старо изискване не е отпаднало при добавянето на ново. Това правило обхваща самия работен запис, преди промяната изобщо да стигне до код.

Човешкият контрол продължава при заявката за промяна: инженерите съпоставят написания код с обхвата и критериите за приемане. В конкретната функционалност изясняването е преместило преработката към тикетите, преди писането на код. То не премахва времето за преглед от колега и не дава основание същият резултат да се обещае за друг проект.

Как задачата стига до Jira Coding Agent

Процесът на Филев използва GitHub Copilot при уточняването на задачите. Отделно инструкцията на Atlassian за Jira Coding Agent описва как агентът започва от Jira задача, получава избрано хранилище и допълнителни указания като важни пътища, стандарти за код и сродни примери. При избраната настройка той може да създаде чернова на заявка за промяна, която хората преглеждат и сливат сами.

Това е различен инструмент от използвания в описания процес на EBRD. Jira Coding Agent действа с правата на човека, който го стартира, и може да извършва някои действия без отделно потвърждение за всяко от тях. Затова правилото на Филев за одобрение преди редакция на тикет трябва да се разглежда като част от неговия процес, а не като автоматична защита във всеки начин за възлагане на код през Jira. За екипа, който получава черновата на кода, решаващата граница остава прегледът срещу записаните изисквания преди приемане на промяната.

Прочетете също:

• ЕС потвърди кода за AI съдържание — законовият етикет остава задължителен
• DXC OASIS сваля времето за решение с 95% — резултатът е фирмен тест
• Claude API или Gemini API: токенът не показва цената на верен резултат