Оптимізація розробки ПЗ: Розподіл ролей ШІ для якості

Проблема єдиної моделі ШІ у розробці ПЗ

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

Крім того, використання однієї моделі створює низку проблем:

Успадкування "сліпих зон": Рецензент успадковує "сліпі зони" кодера, пропускаючи саме ті дефекти, які могла б написати та сама модель.
Залежність від постачальника: Збій, обмеження швидкості або підвищення цін одного постачальника може зупинити весь конвеєр розробки.
Дрейф стилю коду: Кодова база дрейфує до типового стилю однієї моделі, приховуючи місця, які інша модель могла б позначити як незрозумілі.
Неповне тестування: Тестові випадки орієнтовані на режими відмов, які автор вже намагається уникнути, тому реальні граничні випадки залишаються неперевіреними.
Порушення принципів рев'ю: Це порушує принцип залучення різних людей для технічних та кодових рев'ю.

Розподіл ролей між моделями ШІ

Рішення полягає у призначенні різних моделей ШІ для кожного етапу конвеєра розробки. Жодна модель не є досконалою у плануванні, кодуванні, рев'ю та тестуванні одночасно. Кожна модель має свою історію навчання, яка формує те, що вона помічає, а що пропускає. Наприклад, моделі Claude схильні до широкого, пошуку в ширину, тоді як моделі GPT – до вузького, пошуку в глибину. Ці різні інстинкти означають, що дефекти, написані однією моделлю, часто є саме тими, які вона не може виявити під час рев'ю.

Як це реалізувати:

Планування: Виберіть модель, сильну в логічному мисленні, для визначення обсягу завдання через планування в режимі "тільки для читання".
Кодування: Передайте план швидкій, недорогій, оптимізованій для коду моделі, що працює в середовищі, яке автоматично запускає тести.
Рев'ю: Направте рев'ю моделі, яка не писала цей код. Використовуйте недорогу модель для рев'ю, коли є чіткі правила та надійна система.
Тестування: Попросіть модель-рецензента розширити набір тестів граничними випадками, які автор пропустив.
Відстеження: Записуйте, яка модель обробляла кожен етап та її припущення в документі Architecture Decision Record (ADR) або подібному, щоб виявляти повторювані "сліпі зони".
Ротація: Обертайте пари моделей кожні кілька місяців, оскільки їхні сильні сторони змінюються з новими релізами.
TDD-підхід: Застосовуйте правила TDD: одна модель пише тест (Red), інша – найпростішу реалізацію (Green), а третя вирішує, чи варто рефакторити (Refactor).

Переваги підходу

Виявлення більшої кількості дефектів: Модель, яка перевіряє код, написаний іншою моделлю, виявляє саме той клас дефектів, який її власні інстинкти пропустили б.
Уникнення залежності від постачальника: Навантаження розподіляється між постачальниками, тому збій або підвищення цін одного не зупиняє весь конвеєр.
Відповідність вартості складності: Найдорожча модель з сильним логічним мисленням використовується для планування, а рутинна робота з синтаксисом – для дешевшої.
Розширення покриття тестів: Модель з іншими даними навчання може вигадувати граничні випадки, які оригінальний автор ніколи не розглядав.
Запобігання "дрейфу" стилю: Кодова база перестає дрейфувати до звичок однієї моделі та залишається ближчою до власних стандартів.

Дослідження та контекст

Дослідження постачальника інструментів для рев'ю коду Greptile виявило, що запити на злиття (pull requests), написані Claude, мали показник виявлення дефектів 53,7%, коли їх перевіряв сам Claude. Однак, коли той самий код перевіряв GPT, показник виявлення дефектів зростав до 62,0%. Ця закономірність зберігається і у зворотному напрямку для коду, написаного GPT. Перехресне рев'ю моделями – це не хитрість, а прямий результат того, що дві моделі мають різні "сліпі зони". Покладання на одну модель для кожного етапу несе ризик "колапсу моделі", коли якість повільно погіршується без корекції з іншої перспективи.

Міркування та обмеження

Цей підхід додає координаційних витрат, тому він краще підходить для багатоденних функцій, ніж для виправлень в один рядок. Людський контроль перед злиттям коду все ще необхідний, оскільки перехресне рев'ю моделями виявляє більше дефектів, але не гарантує їх відсутність. Важливо відстежувати версії моделей, оскільки типова модель постачальника може змінюватися. Витрати можуть зрости, якщо тривіальні зміни направляються через найдорожчу модель, тому важливо співвідносити модель з фактичною складністю кожного етапу.

Обмеження включають затримку при перемиканні між постачальниками (кожен новий виклик моделі починає "холодний" контекст) та те, що не кожна команда має бюджет або доступ до API кількох постачальників одночасно.

Що це означає для розробників

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

Ключові факти

Призначення різних моделей ШІ для кожного етапу конвеєра розробки ПЗ є ефективнішим, ніж використання однієї моделі.
Одна модель ШІ не може однаково добре виконувати планування, кодування, рев'ю та тестування, а також виявляти власні "сліпі зони".
Розподіл ролей між моделями допомагає виявляти більше дефектів, уникати залежності від одного постачальника та розширювати покриття тестів.
Дослідження Greptile показало, що перехресне рев'ю коду різними моделями (наприклад, GPT рев'ює код Claude) значно підвищує показник виявлення дефектів.
Для ефективного використання рекомендується призначати моделі з сильними логічними здібностями для планування, швидкі та оптимізовані для коду моделі для написання коду, а для рев'ю – моделі, які не писали цей код.