Prompt Fatigue (Промпт-втома та виснаження формулювання)(Промпт-втома та виснаження формулювання)

1. Огляд концепції та системна проблема

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

Prompt Fatigue (Промпт-втома) — це стан когнітивного виснаження, коли розробник ловить себе на думці: "Мені фізично легше відкрити файл і написати ці 10 рядків власноруч, ніж знову пояснювати асистенту, чого я від нього хочу".

Головні драйвери промпт-втоми:

• Семантичний опір: Потреба постійно думати: "Як побудувати фразу так, щоб модель не зрозуміла її двозначно?".
• Ефект зламаного телефону: Багаторазове повторення одних і тих самих контекстних рамок ("ми використовуємо Tailwind v4, а не v3!").
• Втрата відчуття тактильного контролю: Інженер перестає відчувати прямий фізичний контакт з матеріалом коду, перетворюючись на втомленого оператора кол-центру.

Цикл Prompt Churn (Промпт-виснаження):
[Намір: додати валідацію] ---> [Промпт 1: "Додай перевірку email"]
                                         |
                                         v
[Модель додала регулярку, але стерла імпорти] <--- [Роздратування]
                                         |
                                         v
[Промпт 2: "Поверни імпорти назад і залиш регулярку!"]
                                         |
                                         v
[Модель змінила логіку функції] <--- [Гостра фрустрація]
                                         |
                                         v
[Висновок: "Простіше було написати руками за 20 секунд"]

2. Архітектурна таксономія та ментальна модель

Градація інтерфейсів взаємодії за рівнем когнітивного опору:

1. Рівень високого тертя (Interactive Conversational Chat):
   • Робота через вільне вікно чату без структури. Найвищий ризик втоми через непередбачуваність поведінки моделі та необхідність щоразу друкувати довгі речення.
2. Рівень середнього тертя (Inline In-place Prompts — ⌘K):
   • Виділення конкретної ділянки коду з короткою дієслівною вказівкою ("extract component", "add try-catch"). Знижує напругу, оскільки контекст обмежений виділенням.
3. Рівень низького тертя (Voice-to-Text Dictation — Superwhisper / Wispr):
   • Промовляння думок вголос зі швидкістю 150 слів/хв без напруження пальців. Модель локально розпізнає мову та формує чіткий текст.
4. Рівень нульового тертя (Spec-Driven & Declarative Rules):
   • Використання системних інваріантів: .cursorrules, CLAUDE.md, заздалегідь написані TypeScript-інтерфейси. Модель виконує код без жодних промптів природною мовою.

3. Технічний пайплайн та внутрішня механіка

Матриця вибору: Коли промптити, а коли кодити руками

Протокол усунення повторних промптів через Persistent Rules

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

<!-- .cursorrules або AGENTS.md -->
## Project Engineering Invariants
- Николи не видаляй коментарі @deprecated без явної команди.
- Використовуй виключно safeParse() з бібліотеки Zod.
- Усі компоненти повинні бути Server Components за замовчуванням.
- Якщо компонент потребує стану, додавай директиву 'use client' на першому рядку.

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

4. Практичні інженерні сценарії в продакшені

01. Заміна текстового набору промптів на локальне голосове введення

Розробник відчуває біль у зап'ястях і виснаження від набору сотень символів промптів на день. Він встановлює Superwhisper (локальна модель Whisper на базі Metal/GPU на Mac). Замість набору тексту він затискає гарячу клавішу і за 10 секунд наговорює задачу в мікрофон природним тоном. Швидкість постановки задач зростає втричі, а фізична та когнітивна втома падає майже до нуля.

02. Свідоме повернення до ручного кодингу ("Zen Programming")

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

03. Використання тестів замість промптів для виправлення багів

Замість того, щоб 5 разів переписувати промпт "виправ баг, коли користувач передає порожній масив", інженер просто пише один failing unit-тест у Vitest:

it("should return empty array when input is empty", () => {
  expect(parseData([])).toEqual([]);
});

І передає агенту команду з двох слів: "Make tests pass". Модель орієнтується на компілятор і виправляє код з першої спроби.

5. Підводні камені, типові помилки та безпека

1. "Промптинг до посиніння" (The Sunk Cost Prompting Trap): Витративши 20 хвилин на спроби змусити модель згенерувати правильний CSS-глексбокс або регулярний вираз, інженер не може зупинитися через жаль за витраченим часом. Правило стоп-лосу: якщо модель не дала коректного результату з двох спроб, припиніть діалог і напишіть код руками.
2. Параліч через спробу написати "ідеальний промпт": Витрачання 15 хвилин на формулювання тристорінкового "ідеального промпта" для задачі, реалізація якої руками займає 5 хвилин. Не ускладнюйте промпти там, де потрібна проста дія.
3. Емоційне вигорання від антропоморфізації: Спроби сперечатися з моделлю, дратуватися або відчувати образу на "тупість" алгоритму спалюють реальні ресурси нервової системи. Пам'ятайте: LLM — це просто математична матриця прогнозування наступного токена, а не жива людина.