Уточнення контексту проєкту для AI

Перехід від чорновика до робочої системи

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

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

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

Стратегія фіксації готових рішень (Code Freezing)

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

Для запобігання цьому використовується патерн фіксації компонентів:

@startuml
skinparam style plain
skinparam backgroundColor #FFFFFF
skinparam packageBackgroundColor #F8FAFC
skinparam packageBorderColor #1E293B

package "Кодова база проєкту" {
  
  package "Заморожені компоненти (Frozen / Read-Only)" #DCFCE7 {
    [index.html (Каркас сторінки)] as HTML
    [style.css (Дизайн-система та змінні)] as CSS
  }
  
  package "Активна зона змін (Active Target)" #FEF3C7 {
    [main.js (Логіка обробки та валідація)] as JS
  }
}

note bottom of HTML
  Заборонено змінювати розмітку 
  та ідентифікатори (ID)
end note

note bottom of CSS
  Заборонено змінювати 
  кольори та відступи
end note

note bottom of JS
  Дозволено модифікувати 
  обробники подій та розрахунки
end note
@enduml

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

Формулювання оновленого контексту для моделі

Коли діалог з асистентом триває певний час, контекстне вікно накопичує застарілі варіанти коду та проміжні міркування. Щоб повернути системі високу продуктивність і точність, корисно надіслати коротке повідомлення-синхронізацію (Context Refresh).

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

Підсумок поточної версії та обмеження:
1. Статус проєкту: Чорнова версія створена та зафіксована у знімку v0.1-draft.
2. Незмінні компоненти: Розмітка index.html та базові змінні style.css зафіксовані (не змінювати без прямої вказівки).
3. Поточна мета: Перетворити чорновик на першу повністю робочу версію (v1.0-working).
4. Зона фокусу: Написання коректної логіки обробки дій користувача у main.js.
5. Правило розробки: Робимо одну функцію за один крок, перед кодом надавай короткий план дій.

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

Критерії готовності першої робочої версії (Definition of Done)

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

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