Як використовувати ШІ для програмування: процеси, що знижують ризик

Правила безпечної допомоги ШІ в програмуванні

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

Дотримуйтеся такого правила: ШІ може пропонувати, але вирішує ваш репозиторій. Джерело істини, це кодова база, відтворення збою, набір тестів, логи виконання, вимоги до продукту й людське рев'ю. Хороший ШІ-напарник у програмуванні має допомагати вам міркувати на основі цих артефактів, а не замінювати їх.

Правило	Чому це важливо	Що просити в моделі
Спершу відтворіть	Запобігає випадковим патчам	«Перекажи збійну поведінку й докази, перш ніж пропонувати код.»
Тримайте обсяг малим	Знижує ризик регресій	«Запропонуй найменшу безпечну зміну і перелічи змінені файли.»
Зберігайте поведінку	Захищає користувачів і контракти	«Назви інваріанти, які ця зміна не має зламати.»
Вимагайте тестів	Робить відповідь перевірною	«Напиши тести, що падають до виправлення і проходять після.»
Рев'ю перед злиттям	Ловить упевнені помилки	«Переглянь цей діф на коректність, безпеку й пропущені крайні випадки.»

Це стосується всіх моделей. OpenAI, Anthropic та інші постачальники публікують документацію, де описані різні можливості, розміри контексту й способи роботи з інструментами. Ці можливості корисні, але вони не заміняють дисциплінованого робочого процесу. Для інженерної роботи оцінюйте моделі за тим самим стандартом, за яким оцінювали б колегу: чи просять вони бракуючий контекст, чи зменшують невизначеність, чи поважають обмеження і чи лишають слід, який ви можете перевірити?

Робочий процес налагодження

Надійний процес налагодження зі ШІ має п'ять етапів: відтворити, локалізувати, висунути гіпотези, виправити й перевірити. Не починайте зі слів «виправ це». Починайте з доказів. Дайте моделі команду, що падає, точний текст помилки, очікувану поведінку, фактичну поведінку, дотичний код, деталі середовища й будь-яку недавню зміну, яка могла спричинити проблему.

Етап 1: зафіксуйте відтворення. Для бекенду додайте запит, відповідь, код стану, логи й тест, що падає. Для фронтенду додайте маршрут, дію користувача, помилку в консолі браузера, мережеву відповідь, стан компонента і, якщо це доречно, опис скриншота. Для проблем зі збіркою додайте команду, менеджер пакетів, версію Node і повний текст помилки навколо першого збою.

Етап 2: просіть гіпотези, а не код. Уважна модель має проранжувати ймовірні причини й сказати, які докази підтверджують кожну з них. Якщо вона не може розрізнити причини, попросіть найменший діагностичний крок. Це може бути лог, точковий тест, перевірка типів або читання ще одного файлу.

Етап 3: просіть найменший патч. Скажіть моделі не перейменовувати змінні, не переписувати сусідній код, не додавати залежностей і не змінювати публічну поведінку, якщо вона не може обґрунтувати навіщо. Попросіть повернути кореневу причину, начерк патча, змінені файли, тести й ризик.

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

Промпт для налагодження:

Дій як уважний напарник із налагодження. Поки що не пиши код. Спершу перекажи відтворення, очікувану поведінку, фактичну поведінку і три найімовірніші кореневі причини. Проранжуй кожну причину за доказами. Потім запропонуй найменший діагностичний крок. Баг: [опишіть]. Команда або дія користувача: [вставте]. Помилка або логи: [вставте]. Дотичний код: [вставте]. Обмеження: [стек, файли, які не можна чіпати, поведінка, яку треба зберегти].

Промпт для виправлення:

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

Робочий процес рев'ю коду

ШІ часто кращий у ролі рецензента, ніж у ролі першого автора. Коли ви просите переглянути діф, він може шукати пропущені крайні випадки, проблеми з безпекою, застарілі припущення, прогалини в тестах і зміни поведінки. Головне, зробити рев'ю конкретним. Якщо ви спитаєте «як тобі, нормально?», ви отримаєте ввічливе схвалення. Якщо ви спитаєте про ризик некоректності, значно ймовірніше отримаєте корисні заперечення.

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

Ділянка рев'ю	На що має відповісти ШІ
Коректність	Чи справді діф виконує вимогу?
Ризик регресій	Яка наявна поведінка може змінитися випадково?
Безпека	Чи опрацьовано вхідні дані, авторизацію, секрети, права та ін'єкції?
Обробка помилок	Що буде за null, таймаутів, повторів, поганих відповідей чи часткового стану?
Тести	Які твердження про поведінку не покриті?
Підтримуваність	Чи дотримано місцевих патернів і чи зрозуміла зміна?

Промпт для рев'ю коду:

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

Для змін із високим ризиком використовуйте порівняння виправлень від різних моделей у Whizi. Запустіть той самий промпт для рев'ю у двох або трьох моделях. Якщо одна модель знаходить можливу проблему, не приймайте це на віру: перевірте, чи проблема справді існує у вашій кодовій базі. Мета не в тому, щоб зібрати більше думок. Мета в тому, щоб розширити поле огляду перед злиттям.

Робочий процес рефакторингу й тестів

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

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

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

Крок 3: напишіть характеризаційні тести. Перш ніж змінювати код, попросіть ШІ визначити поточну поведінку й скласти тести, які фіксують важливі випадки. Такі тести особливо корисні для успадкованого коду, де намір автора неясний. Вони мають охоплювати звичайні вхідні дані, граничні значення, шляхи збою й один регресійний випадок, пов'язаний із причиною рефакторингу.

Крок 4: реалізуйте по одному етапу за раз. Після кожного етапу запускайте тести й просіть точкове рев'ю. Якщо модель пропонує широку абстракцію, змусьте її довести, що ця абстракція прибирає реальне дублювання або ризик. Інакше тримайте код нудним і локальним.

Промпт для планування рефакторингу:

Склади поетапний план рефакторингу. Мета: [мета]. Поточний код: [вставте]. Обмеження: зберегти публічну поведінку, мінімізувати обсяг змін, дотримуватися наявних патернів, не додавати залежностей, тримати кожен етап тестованим. Поверни: інваріанти, карту залежностей, етапи, змінені файли, тести на кожен етап, ризик відкату й чек-лист для рев'ю.

Промпт для юніт-тестів:

Напиши тести до змін у реалізації. Використовуй наявний стиль тестів, показаний тут: [вставте]. Поведінка, яку треба зберегти: [вставте]. Код, що тестується: [вставте]. Поверни назви тестів, підготовку, вхідні дані, очікуваний результат і те, чому кожен тест важливий. Додай щасливий шлях, граничний випадок, випадок помилки й регресійний випадок.

Шаблони промптів

Сильні промпти для програмування довгі не тому, що вони вигадливі. Вони довгі рівно настільки, щоб прибрати двозначність. Моделі потрібні роль, завдання, контекст, обмеження, формат виводу й критерії перевірки. Зберігайте промпти, які працюють, щоб ШІ став повторюваним інженерним процесом, а не разовою розмовою.

Промпт для пояснення коду:

Поясни цей код для розробника, який щойно приєднався до проєкту. Опиши призначення, вхідні дані, результати, потік даних, залежності, режими збою й тести, які підвищили б упевненість. Відділи факти, видимі в коді, від припущень. Код: [вставте].

Промпт для безпечного коду:

Переглянь цей код на предмет ризиків безпеки. Зосередься на автентифікації, правах доступу, ін'єкціях, секретах, валідації, небезпечних редиректах, роботі з файлами, ризиках залежностей і витоку чутливих даних. Поверни лише проблеми з доказами, впливом, пропонованим виправленням і тестом або ручною перевіркою. Код або діф: [вставте].

Промпт для порівняння виправлень від моделей:

Я порівнюю моделі ШІ на завданні з програмування. Використовуй лише наданий контекст. Поверни кореневу причину, найменше безпечне виправлення, тести, ризики, припущення й запитання. Оціни свою впевненість від 1 до 5 і перелічи, які докази змінили б твою відповідь. Завдання: [вставте]. Контекст: [вставте].

Чек-лист перевірки, перш ніж прийняти написаний ШІ код:

• Модель правильно переказала завдання.
• Патч менший за проблему, а не більший.
• Публічну поведінку й контракти названо.
• Тести прямо покривають баг або мету рефакторингу.
• Крайні випадки й шляхи збою перелічено.
• Чутливі до безпеки вхідні дані переглянуто.
• Діф відповідає наявним патернам проєкту.
• Ви запустили відповідний тест, лінтер, збірку або ручне відтворення.
• Людина переглянула фінальний діф.

Whizi корисний тоді, коли ви хочете порівняти виправлення, не змінюючи завдання. Вставте той самий промпт для налагодження чи рев'ю в кілька моделей, а потім оцініть результати за доказами, обсягом, тестами й ризиком. Почніть із альтернатив ChatGPT для програмування, якщо вам потрібен посібник із вибору моделі, порівняйте плани на сторінці цін або створіть акаунт, щоб запустити цей процес на власному коді.