Стратегія завдань для AI-розробки

Проблема поспішної генерації коду

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

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

@startuml
skinparam style plain
skinparam backgroundColor #FFFFFF
skinparam sequenceMessageAlign center

actor "Розробник (Student)" as Dev #DBEAFE
participant "AI Assistant" as AI #DCFCE7
participant "Кодова база" as Code #FEF3C7

Dev -> AI : Запит із вимогою: "Опиши покроковий план, але НЕ пиши код"
activate AI
AI --> Dev : Покроковий план змін (Step 1, Step 2, Step 3)
deactivate AI

Dev -> Dev : Аналіз плану: чи немає зайвих дій або помилок?
alt План коректний
  Dev -> AI : "План затверджено. Реалізуй Крок 1 у main.js"
  activate AI
  AI -> Code : Генерація точкового коду для Кроку 1
  deactivate AI
else План містить помилку
  Dev -> AI : "Спершу скоригуй Крок 2: ми не використовуємо alert()"
end
@enduml

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

Правило атомарної ітерації: одна функція за раз

Найчастіша причина втрати працездатності застосунку у новачків — спроба вирішити кілька завдань в одному повідомленні.

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

Анатомія ефективного інженерного промпту

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

1. Цільова дія: що саме потрібно зробити (дієслово в наказовій формі).
2. Точна локалізація: у якому саме файлі та якій функції відбуваються зміни.
3. Очікувана поведінка: як саме система має реагувати на дії користувача.
4. Заборонені дії (негативні обмеження): що категорично заборонено змінювати або видаляти.

Завдання на ітерацію:
Реалізуй логіку розрахунку часу читання у файлі main.js.

Вимоги:
1. Отримай значення з поля введення #page-count та селектора #text-complexity.
2. При натисканні на кнопку #calc-btn обчисли загальний час за формулою:
   - Легкий текст: 2 хвилини на сторінку.
   - Середній текст: 3 хвилини на сторінку.
   - Складний текст: 5 хвилин на сторінку.
3. Виведи підсумкове число хвилин усередині елемента #result-value.
4. Зроби блок #result-container видимим (видали клас .hidden).

Обмеження:
- НЕ змінюй розмітку index.html.
- НЕ використовуй сторонні бібліотеки.
- Не чіпай стилі в style.css.

Стратегія коригування при неповному результаті

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

Замість цього застосовується коригуючий промпт:

1. Подякуйте за виконану частину або підтвердіть її працездатність: «Розрахунок працює коректно, значення обчислюється правильно».
2. Вкажіть на конкретний відсутній елемент: «Проте блок результату (#result-container) не з'являється на екрані, оскільки з нього не знімається клас .hidden».
3. Поставте точкову вимогу: «Додай один рядок для зняття класу .hidden з контейнера при успішному розрахунку. Решту коду не змінюй».

Практичні завдання та запитання для самоконтролю