Я і -діод- копайлот

Даний текст є рефлексією до використання ШІ інструментів, він не ставить на меті порівняння доступних реалізацій ШІ інструментів для розробки ПЗ чи надати кращі практики по темі.

За декілька років хайпу навколо ШІ я так і не почув масштабованих сценаріїв використання ШІ, які дозволили б суттєво покращити якість процесу розробки досвідченим спеціалістом. Тому десь півтора місяці назад я вирішив спробувати цілеспрямовано інтегрувати ШІ в щоденні процеси. Найкраще описати досвіди використання буде на 3 основних прикладах:

Алгоритмічна задача. Перевірити, що в певні зони зображення є повністю прозорими.
Конфігураційна. На основі бізнес вимог описати конфігурацію, що перевіряє медіа файл.
Бізнесова. Створити плагін, який на основі даних з БД формує документ у визначеному форматі. Додаткові сценарії:
Генерація тестів.
ПоК, початкове налаштування проєкту та тестове завдання.
Пошук відповіді на питання по технології чи по проєкту.

Трохи про проєкт. Це група мікросервісів на тайпскріпт. Використовувався гітхаб копайлот в вскод.

Алгоритмічна задача

З задачею діставання прозорих зон з зображення та пошуку перетину цих зон з вказаними прямокутниками ШІ справився чудово. Як і зі схожими задачами обходу деревовидних структур. Ці задачі дуже близькі до того, що вивчають в університетських курсах чи до задач на літкод, підозрюю, що усі моделі так чи інакше тренувались на цих прикладах.

Задача розвʼязувалась в припущенні, що прозорих зон у зображенні мало, тому мало сенс їх усі дістати і відправити на сервіс валідації. Але виявилось, що бізнес хоч і підтвердив це все ж має бізнес процеси завантаження великих зображень з купою прозорих зон. Тому було прийнято рішення попросити копайлот обмежити екстракцію лише певними смугами по осі У. І тут перша “ложка дьогтю” — фікс виглядав як просто контінью там де координата У не входить у вказані значення. Але з підказкою він досить легко оптимізував рішення. Проте даний приклад показує, що «здатність думати» у ШІ на рівні навіть не джуна, а студента перших курсів (і то не найкращого).

Ще один неприємний висновок — це підтвердження жарту «ми хотіли, щоб машини займались рутиною, поки ми займаємось мистецтвом, а сталось навпаки — машини займаються цікавими задачами, а люди рутиною».

Конфігураційна

Задача: десь у Слак хтось скинув посилання на конфлюенс де описано вимоги до медіа файлів, треба додати правила валідації на основі тих вимог.

Тут на допомогу копайлоту приходить glean. Копайлот, принаймні в доступній мені конфігурації, не має можливості сходити за посиланням та розпарсити сторінку, навіть якби я вам те посилання. Але можна попросити глен знайти специфікації, які мені потрібні, і надати у структурованій формі (я все ж перевірив, що його відповідь співпала з тим, що у знайдених посиланнях). Далі цей опис передається копайлоту і той створює конфігурації. Тут важливий момент, що стало помітно, що різні моделі дещо по різному справляються з цією задачею: чатгпт багато галюцинував, тому я остаточно переключився на сонет, який по відчуттям краще працює (але як там ціна я не знаю).

Бізнесова

Тут ШІ показав чи не найгірші результати, багато галюцинацій. Але і задача йому ставилась «просто» — створи плагін, що має таку структуру вхідного обʼєкту, за прикладом існуючих плагінів, потім було додано приклад очікуваного вихідного документа. Можливо додавання прикладу одразу і чіткий опис усіх деталей реалізації допоміг би покращити результат, але якщо описувати детально задачу чату, то десь те саме я можу зробити і в коді. З подальшими підказками все ж вдалось отримати задовільний результат, але по часу це не була економія, але веселіше — є з ким поговорити в умовах ремоут роботи (дісклеймер для менеджерів: це не аргумент за повернення в офіс).

В принципі покрокове флоу «додай тести — зроби, щоб тести проходили» в даному випадку теж могло б допомогти. Проте з таким рівнем контролю за процесом, ми економимо на найдешевшому — на написанні коду, лишаючи аналіз та моделювання в повній мірі на розробнику.

Генерація тестів

Знову ж досить контроверсійний сценарій. З одного боку добре було б перекласти аналіз на машину, з іншого не ясно яким чином перевіряти результати її роботи. Тут варто відмітити, що різні моделі по різному, але робили «биті тести». Наприклад, ШІ що генерує багато вхідних даних в деяких випадках замість генерації цих даних вставив коментар «тут має бути ще Х таких самих строк»; дякую звісно, що написав, але я це знаю і мені були потрібні саме ті строки.

Проте з задачею генерації тестів ШІ справляється скоріше добре ніж ні, але це за умови, що у вас вже є певна база якісних тестів в проєкті. Також на моєму проєкті сонет генерував значно кращі тести, часто з узагальненням у параметризовані тести, ніж чатгпт, але це не означає, що у вас буде так само.

ПоК, початкове налаштування проєкту та тестове завдання

Схожа задача на написання тестів — це генерація скріптів для тестування АПІ на різних оточеннях. В проєкті багато інтеграційних тестів. Коли стала задача створити певну сутність на різних оточеннях (це вимагає багато кроків), то просто попросив на основі тестів створити баш-скрипти. Тут ШІ справився цікаво:

скрипти мали деталізований вивід (з красивими ікониками та кольорами);
розвинені можливості конфігурації, можливо навіть занадто розвинені, бо в змінні оточення було винесено чи не все, що можна було;
власне бізнесова частина — джсони для створення містили 1 помилку, чомусь за основу було взяти негативний приклад з тестів. Це демонструє, що ШІ досить непогано все ж справляється з задачами, не мають бізнес специфіки вашого проєкту — додати систему авторизації, налаштувати логування, ЦІ пайплайни (але теж може залежати від популярності вашої білд системи, мобільщики та дотНетчики жалілись, що ШІ не дуже добре «знає» їх типові рішення) і тд. Та сама історія з ПоК, що зводяться до «спробувати технологію»; як ШІ поведе себе в сценаріях «вибору технології збереження даних для певних вимог» — треба дивитись.

Ну і моя улюблена тема — тестові (домашні) завдання. Тут ШІ має найбільші перспективи, ці завдання часто мають детальний опис кроків, включають або базові знання технології, або алгоритмів, і максимально схожі на університетські приклади. Власне десь більше року тому, я проганяв задачу «привести код до відповідності правилам чистого коду», ШІ справився. Кілька знайомих робили ДЗ на 8+ годин за 1-2 години, генеруючи купу всього за допомогою ШІ. Те що один з цих знайомих чудово зробив ДЗ по Джанго не маючи досвіду з ним нехай буде сюрпризом для його нового роботодавця, проте думаю той знайомий все ж здатен шукати потрібну інформацію швидко, то можливо роботодавець і не помітить.

Пошук відповіді на питання по технології чи по проєкту

Гугл на стероїдах — це був чи не єдиний очевидний сценарій для застосування ШІ. І з ним машина гарно (відносно) справляється. Галюцинації в типових темах вже майже відсутні або їх значно менше ніж було рік чи два тому. Але все ще трапляються анекдоти. Якимсь чином замість обʼєкта в протобаф експорт потрапляв завжди пустий об’єкт. Ми на дзвінку не змогли розібратись, тому я запитав у копайлота чому це може бути (він був в режимі запитання, а не агента). Поки ми розмовляли і пробували зрозуміти, що відбувається, копайлот почав генерувати приклади коду на пайтон, джава, джаваскріпт та го (нагадую, що проєкт на тайпскріпті) та просити їх запустити, щоб провести експеримент. В даному сенсі ШІ максимально схожий на справжніх розробників — замість того, щоб ознайомитись з документацією чи подивитись вихідні коди бібліотеки, він пише код і пробує його запустити. Якщо комусь цікаво, то проблема була в тому, що для Struct подів їх треба явно конвертувати за допомогою утиліти з бібліотеки, а не просто передавати об’єкт.