У Лондоні інженер і викладач Метт Поко́к провів двогодинний воркшоп з AI‑асистованої розробки для практикуючих інженерів. На прикладі публічного репозиторію з вправами та використовуючи Claude Code, він показував, як будувати реальні робочі процеси з великими мовними моделями (LLM). Один із ключових блоків цієї сесії — не про інструменти чи фреймворки, а про фундаментальну «фізику» LLM: як поводиться модель, коли ви нарощуєте контекст, де проходить межа між «розумною» та «тупою» зоною і чому правильне управління контекстом важливіше за гігантські вікна на мільйон токенів.
![[FULL WORKSHOP] AI Coding For Real Engineers - Matt Pocock,](http://localhost:5000/images/-QFHIoCo-Ko/en/thumbnail_web.jpg)
Коли LLM починає тупити: інтуїція «розумної» та «тупої» зон
Початковий образ, з якого стартує Поко́к, — поділ роботи LLM на «smart zone» і «dumb zone». Ідея належить засновнику компанії Human Layer Дексу Хаю, але в руках практикуючого інженера вона перетворюється на прикладну евристику для щоденної розробки.
У «розумній зоні» модель працює з відносно невеликим контекстом: нова сесія, чистий діалог, мінімум історії. У цей момент увага моделі розподіляється по токенах без надмірного навантаження, і відповіді виглядають найбільш точними, структурованими та передбачуваними.
Щоб пояснити, що відбувається далі, Поко́к пропонує аналогію з футбольною лігою. Кожен новий токен у контексті — як додаткова команда в лізі: з кожною командою кількість можливих матчів зростає не лінійно, а квадратично. Так само й у трансформерних моделях: кожен токен потенційно взаємодіє з усіма іншими через механізм attention. Чим більше токенів, тим більше пар взаємодій, тим важче моделі «тримати в голові» релевантні зв’язки.
У якийсь момент ця складність починає працювати проти якості. Формально контекст може сягати сотень тисяч або навіть мільйона токенів, але це не означає, що модель однаково добре «розуміє» все, що в нього завантажено. Поко́к пропонує практичну, а не теоретичну межу: приблизно від 100 тисяч токенів LLM поступово входить у «тупу зону».
Це не жорсткий поріг, а радше точка, після якої інженер повинен бути особливо уважним. Незалежно від того, чи працюєте ви з вікном на 200 тисяч або на мільйон токенів, близько цієї позначки модель починає частіше робити дивні висновки, губити важливі деталі, суперечити сама собі. Суб’єктивне відчуття багатьох розробників — «AI раптом почав нести нісенітницю» — добре корелює з тим, що контекст просто вийшов за межі «розумної зони».
Звідси перший практичний висновок: розмір контекстного вікна — це не ліцензія «засунути туди все». Навпаки, чим ближче ви до 100 тисяч токенів, тим більше шансів, що модель почне поводитися менш надійно, навіть якщо формально ліміт ще далеко.
Маленький системний промпт як стратегічна перевага
Якщо прийняти, що «розумна зона» обмежена, постає питання: на що саме витрачати цей дефіцитний ресурс? Поко́к пропонує дивитися на сесію з LLM як на послідовність фаз, що завжди починається з системного промпту.
У його уявленні системний промпт — це сірий блок, який завжди присутній у контексті. Це може бути опис ролі агента, інструкції з безпеки, стиль відповіді, специфіка проєкту. Усе, що ви покладете сюди, буде «з’їдати» частину вашої «розумної зони» ще до того, як модель почне робити корисну роботу.
Поко́к бачив конфігурації, де в системний промпт зашивали до 250 тисяч токенів — фактично цілі документації, кодові бази, довгі маніфести. Формально це можливо, але з точки зору продуктивності це означає стартувати сесію вже в «тупій зоні». Модель ще не отримала жодного конкретного завдання, а її увага вже розмазана по сотнях тисяч токенів, більшість з яких у конкретній задачі можуть виявитися нерелевантними.
Тому рекомендація проста й жорстка: системний промпт має бути «якнайменшим». У ньому — лише те, що справді потрібно в кожній сесії, без енциклопедичних вставок. Усе, що можна подати як окремий фрагмент контексту в момент, коли це стане потрібним, краще не тримати постійно в «сірому блоці».
Це змінює спосіб мислення про промпт‑інжиніринг. Замість того щоб будувати «ідеальний, всеохопний» системний промпт, варто мислити ним як мінімальним ядром, навколо якого динамічно підвантажується решта інформації. Чим менше ядро, тим більше простору залишається для поточної задачі в межах «розумної зони».
Розмір задачі важливіший за розмір контексту
Якщо системний промпт має бути компактним, наступний логічний крок — переглянути розмір самих задач, які ми віддаємо LLM. Поко́к прямо пов’язує це з класичними порадами зі світу «людської» розробки: не братися за завдання, що не поміщається в голову, розбивати великі фічі на менші, уникати «захлистання» складністю.
У випадку з AI‑асистованою розробкою це означає: кожна окрема задача для моделі має комфортно вміщуватися в «розумну зону». Не варто покладатися на те, що «в нас же мільйон токенів, хай модель сама розбереться». Формально вона зможе прочитати все, але практично ймовірність помилок, пропусків і дивних рішень різко зросте.
Поко́к описує типовий анти‑патерн, який сьогодні спокушає багатьох команд. Вони беруть велику ціль — умовно «клонувати компанію» або реалізувати масивну фічу — і починають «просто йти вперед» в одному й тому ж діалозі. Контекст росте, рахунок за токени теж, модель поступово скочується в «тупу зону». Щоб якось це контролювати, розробники періодично «компактують» історію, стискаючи її в коротші резюме, і продовжують рухатися далі вже з цими стислими записами.
На папері це виглядає як розумна стратегія економії контексту. На практиці, за спостереженнями Поко́ка, вона часто призводить до накопичення помилок. Кожне стиснення — це інтерпретація, де щось втрачається, щось спотворюється, щось подається в іншому порядку. З часом цей «осад» неточностей накопичується, і модель починає спиратися на історію, яка вже мало схожа на реальний перебіг подій.
Звідси його порада: замість того щоб намагатися «протягнути» одну гігантську задачу через нескінченний діалог, варто спроєктувати роботу так, щоб кожен крок був самодостатнім і поміщався в «розумну зону». Великі цілі розбиваються на послідовність менших задач, кожна з яких має чіткий вхід, очікуваний вихід і не вимагає від моделі тримати в голові всю історію проєкту.
Це не означає відмову від складних фіч чи довгих ініціатив. Це означає, що архітектура роботи з LLM має бути фазовою й модульною, а не монолітною. Поко́к пізніше в воркшопі говорить про багатофазні плани, цикли та агенти, але базовий принцип залишається тим самим: модель має працювати з тим обсягом контексту, в якому вона залишається «розумною».
Модель як герой «Мементо»: чому очищення контексту краще за компактування
Другий фундаментальний образ, який використовує Поко́к, — фільм «Memento». Головний герой стрічки страждає на короткочасну амнезію й постійно повертається до базового стану, забуваючи щойно пережите. Поко́к пропонує дивитися на LLM приблизно так само: кожне очищення контексту повертає модель у «нульову» точку, де в неї є лише системний промпт і жодної пам’яті про попередню розмову.
У типовій сесії, за його описом, відбувається кілька фаз. Після системного промпту модель входить в «експлоративну» фазу: досліджує кодову базу, ставить уточнювальні питання, формує розуміння задачі. Потім настає фаза імплементації, де пишеться код, вносяться зміни. Далі — тестування, запуск зворотних зв’язків, перевірка результатів. Усе це відбувається в одному контексті, поки розробник не натисне «очистити».
Коли контекст очищується, усе, що було в цих фазах, зникає. Модель більше не пам’ятає, які саме файли вона читала, які питання ставила, які компроміси приймала. Вона знову бачить лише системний промпт — той самий «сірий блок», який, за порадою Поко́ка, має бути максимально компактним і стабільним.
Багатьом розробникам така поведінка здається неприродною, і вони намагаються її «обійти» через компактування. Ідея проста: замість того щоб повністю втрачати історію, можна стиснути її в короткий текстовий підсумок і залишити в контексті як «історію сесії». Так модель начебто зберігає пам’ять про те, що відбувалося, але в набагато меншій кількості токенів.
Поко́к визнає, що цей підхід популярний — «деви люблять компактування» — але сам ставиться до нього вкрай скептично. Його головний аргумент — передбачуваність. Коли ви очищуєте контекст, ви завжди повертаєтеся до одного й того ж базового стану. Системний промпт незмінний, модель не несе із собою жодних «привидів минулих сесій». Кожен запуск — як новий старт, з чітко визначеними вхідними даними.
Компактування ж створює проміжний, напівстабільний стан. Історія сесії вже не повна, але й не відсутня. Вона переписана в іншій формі, з іншими акцентами. Модель починає спиратися на цей конденсований наратив, який сам по собі є продуктом її ж роботи. Якщо в ньому закралася помилка, вона буде тиражуватися далі. Якщо щось важливе було опущено, модель не зможе до цього повернутися.
Поко́к описує це як накопичення «осаду» в контексті. Кожне нове компактування додає ще один шар інтерпретацій поверх попередніх. З часом стає все важче зрозуміти, де закінчується реальна історія проєкту й починається її спотворене відображення в стиснених резюме.
Тому його особиста стратегія — максимально уникати компактування й віддавати перевагу повному очищенню контексту. Краще ще раз явно подати моделі потрібні фрагменти коду чи документації, ніж намагатися «протягнути» через кілька сесій напівзабуту історію. У світі, де LLM і так мають схильність «вигадувати» деталі, додатковий шар непрозорої пам’яті лише збільшує ризики.
Лічильник токенів як інструмент безпеки
Усе це — про стратегію. Але щоб стратегія працювала, потрібні тактичні інструменти. Один із них у Поко́ка — банальний, але критично важливий лічильник токенів у середовищі розробки.
Під час воркшопу він працює в Claude Code, але наголошує, що принципи універсальні для будь-якої LLM. У нижній частині інтерфейсу в нього виведений невеликий статус‑рядок, який показує точну кількість токенів у поточній сесії. Це не декоративний елемент, а, за його словами, «essential information» — життєво важлива інформація для кожної сесії.
Лічильник дозволяє в реальному часі бачити, наскільки ви наблизилися до «тупої зони». Якщо контекст стрімко росте й підбирається до умовної позначки в 100 тисяч токенів, це сигнал: час або завершувати поточну задачу, або очищувати контекст і починати нову фазу з чистого аркуша. Без такого індикатора розробник легко може «проспати» момент, коли модель починає деградувати, і списати дивну поведінку на «капризи AI», а не на перевантажений контекст.
Поко́к навіть публікував окрему статтю на своєму сайті AI Hero про те, як реалізувати подібний лічильник у власному середовищі. Але ключова думка не в конкретній реалізації, а в самому підході: робота з LLM має бути вимірюваною. Якщо ви не бачите, скільки токенів споживає сесія, ви фактично працюєте наосліп, і всі розмови про «розумну» й «тупу» зони залишаються теорією.
Лічильник токенів перетворює ці зони на практичний інструмент планування. Ви можете свідомо вирішувати, коли варто ще трохи розширити контекст, а коли — зупинитися й перезапустити сесію. Це наближає роботу з LLM до класичної інженерної дисципліни, де ресурси вимірюються й контролюються, а не сприймаються як безмежні.
Як виглядає здорова сесія: фази, а не нескінченний чат
У підсумку Поко́к пропонує дивитися на кожну сесію з LLM як на структурований процес із чіткими фазами, а не як на безкінечний чат, у який можна нескінченно додавати нові повідомлення.
Спочатку — невеликий, стабільний системний промпт. Потім — фаза дослідження, де модель знайомиться з кодовою базою, ставить питання, уточнює вимоги. Далі — фаза імплементації, де вона вносить конкретні зміни. Потім — тестування й перевірка результатів. Після завершення логічного блоку роботи — очищення контексту й повернення до базового стану.
Кожна з цих фаз має бути спроєктована так, щоб уміщуватися в «розумну зону». Якщо завдання виходить за ці межі, його потрібно розбити на менші частини. Замість того щоб тягнути за собою всю історію, краще передавати між фазами лише те, що справді необхідно, у вигляді чітко сформульованих артефактів — наприклад, коротких описів задач, конкретних фрагментів коду, тестових сценаріїв.
Такий підхід змінює саму культуру роботи з AI‑інструментами. Замість спокуси «звалити все на модель» і чекати магії, інженер бере на себе відповідальність за структурування задач, управління контекстом і контроль за ресурсами. LLM у цій картині — потужний, але обмежений інструмент, який потрібно використовувати з розумінням його внутрішніх обмежень.
Висновок: великі вікна не скасовують інженерної дисципліни
Головний меседж Поко́ка до аудиторії інженерів простий: AI — це новий потужний інструмент, але не нова фізика. Базові принципи хорошого софту — розбиття задач, контроль складності, чіткі фази роботи — працюють тут так само, як і в «додоботному» світі.
Концепція «розумної» й «тупої» зон нагадує, що навіть найбільші контекстні вікна мають практичні межі. Приблизно від 100 тисяч токенів модель починає деградувати, і завдання інженера — не доводити її до цього стану без потреби. Маленький системний промпт, задачі, що поміщаються в «розумну зону», відмова від нескінченного компактування на користь чистих перезапусків і постійний моніторинг кількості токенів — це не дрібні оптимізації, а фундаментальні елементи надійного AI‑воркфлоу.
У світі, де маркетинг LLM обіцяє «мільйон токенів у контексті» й «агентів, які зроблять усе за вас», такий тверезий, інженерний погляд особливо цінний. Він повертає фокус із розміру моделей на якість процесів і показує, що справжня продуктивність у AI‑розробці народжується не з магії, а з дисципліни.
This makes financial planning easier.