Cognitive Context Thrashing(Когнітивний трешинг перемикання завдань)

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

З появою інструментів паралельного запуску агентів у розробників з'явилася небезпечна спокуса:

• В одній вкладці терміналу агент переписує компонент аутентифікації.
• У другій вкладці інший агент налаштовує Grafana-дашборди.
• У третій — агент шукає витік пам'яті у веб-сокетах.
• А в четвертій розробник намагається відповідати в робочому чаті Slack.

Через 45 хвилин такої "роботи" наступає Cognitive Context Thrashing (Когнітивний трешинг): Агент 1 подає сигнал про завершення. Інженер дивиться на 200 рядків коду і 3 хвилини згадує, чому взагалі він дав таку задачу. Тільки-но контекст відновився — блимає Агент 2. Мозок витрачає всі запаси глюкози на перемикання контексту, а реальний корисний вихід дорівнює нулю.

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

┌─────────────────────────────────────────────────────────────┐
│                 HUMAN BRAIN CONTEXT THRASHING               │
├─────────────────────────────────────────────────────────────┤
│ 1. THE MYTH OF PARALLEL BRAIN EXECUTION:                    │
│    [Agent A: Auth]   [Agent B: Billing]   [Agent C: Infra]  │
│           │                  │                  │           │
│           └──────────────────┼──────────────────┘           │
│                              ▼                              │
│ 2. SINGLE-THREADED HUMAN PREFRONTAL CORTEX:                 │
│    • Context Switch Latency: 15–20 minutes to deep focus    │
│    • Total Available Working Memory: ~4 chunks of data      │
├─────────────────────────────────────────────────────────────┤
│                          │                                  │
│                          ▼ RESULT                           │
│ 3. COGNITIVE BROWNOUT:                                      │
│    • 80% енергії витрачено на згадування умов таски         │
│    • Сліпе схвалення помилкових дифів без глибокого аналізу │
│    • Головний біль та відчуття хаосу наприкінці дня         │
└─────────────────────────────────────────────────────────────┘

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

01. Правило суворого обмеження роботи в процесі (WIP = 1)

Інженер забороняє собі запускати наступну таску для моделі, доки поточна задача не завершена, не протестована і не закомічена в Git. Повна концентрація на одному завданні дає втричі вищу якість і меншу втому.

02. Використання письмових статусів для асинхронності

Якщо задачу довелося відкласти, інженер витрачає 60 секунд на запис у файл current_status.md: "Зупинився на конфлікті міграцій 004, наступний крок — перевірити enum тип". Це дозволяє повернутися до контексту без трешингу.

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

• Ілюзія "Я все встигаю": Одночасне миготіння трьох терміналів дає оманливе відчуття динаміки та зайнятості. Не плутайте рух із реальним інженерним прогресом.
• Вимкнення сповіщень: Звукові сигнали про завершення кожного кроку агента розривають концентрацію. Вимикайте звуки — дивіться на результати тоді, коли ви самі завершили поточний блок роздумів.

5. Стратегічний висновок для інженера 2026 року

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