Як досвідчені розробники використовують ШІ по-іншому

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

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

Нечіткі запити проти контекстних брифів

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

Контекст дає асистенту змогу обрати між правдоподібними технічними варіантами. Без нього асистент може оптимізувати видимий код, а не справжню проблему користувача.

Відповіді спочатку проти аналізу спочатку

Короткий запит на реалізацію доречний для очевидної утиліти. Він ризикований для переходів стану, володіння даними, перевірок дозволів або виробничого збою.

Промпт із аналізом спочатку має такий вигляд:

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

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

Асистент спершу стає партнером із дослідження. Розробник може перевірити модель системи до прийняття патчу.

Великі зміни проти поетапних змін

Одне широке завдання може поєднати виправлення помилки, рефакторинг, переписування тестів і зміну стилів. Через це важко побачити причинно-наслідковий зв’язок.

Натомість використовуйте контрольні точки:

1. Відтворіть збій і опишіть поточний шлях.
2. Внесіть найменше виправлення поведінки.
3. Додайте цільовий регресійний тест і запустіть його.
4. Покажіть diff і окремо поясніть залишене очищення.

Це не зайва бюрократія. Невеликі зміни роблять перевірку, відкат і реагування на інциденти безпечнішими.

Довіряти результату проти перевіряти результат

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

Статичні перевірки: перевірка типів, лінтинг, валідація схем.
Перевірки поведінки: цільові модульні або інтеграційні тести.
Перевірки продукту: ручний сценарій, що відповідає проблемі користувача.
Перевірки рев’ю: огляд diff на регресії меж завдання, дозволів, локалі та побічних ефектів.

Попросіть асистента запропонувати ці перевірки, а потім самостійно запустіть потрібні. Якщо перевірку неможливо виконати локально, зафіксуйте прогалину замість заяви про успіх.

Мислення «реалізація спочатку» проти «проблема спочатку»

Перша ідея реалізації часто є найдорожчим способом розв’язати симптом. Починайте з проблеми:

Проблема: Учень втрачає поточне завдання після перемикання вкладок браузера на
малому екрані.

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

Це залишає простір для простішої відповіді: виправлення маршрутизації, застарілого стану або іншої мобільної взаємодії.

Звички досвідчених розробників — це звички рев’ю

Найбільш переносимий шаблон — не «використовуйте певну модель» і не «пишіть довші промпти». Це здатність зробити роботу придатною до перевірки:

Поясніть, чому зміна важлива.
Укажіть, що має лишитися істинним.
Запитайте, які докази можуть спростувати план.
Обмежте першу зміну.
Визначте доказ того, що вона спрацювала.

Так хороший колега думає про задачу або pull request. ШІ лише робить потребу в явному контексті помітнішою.

Шаблон промпту, який варто застосувати

Проблема: [Вплив на користувача або систему.]
Докази: [Відтворення, тест, що падає, журнали або поточна поведінка.]
Припущення: [Що, на вашу думку, може відбуватися.]
Межі завдання: [Що слід дослідити насамперед.]
Обмеження: [Що не повинно змінитися.]
Результат: [Спостережний успіх.]
Перевірка: [Тести, ручний шлях, вимірювання, рев’ю.]

Проаналізуйте поточну поведінку до редагування. Поставте припущення під сумнів і
запропонуйте найменшу зміну, підтверджену доказами.

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

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