На конференціях про штучний інтелект дедалі частіше говорять про «агентів», «автономне програмування» й «мільйонні контексти». Але за гучними термінами легко загубити головне запитання: як це все організувати так, щоб реальні інженери могли реально працювати й отримувати результат, а не просто дивитися на демо?
Британський інженер і викладач Метт Поко́к, відомий за своїми матеріалами про TypeScript та AI-асистовану розробку, намагається відповісти саме на це запитання. На воркшопі «AI Coding For Real Engineers», який триває близько двох годин і орієнтований на практику, він показує не лише техніки роботи з LLM, а й те, як побудувати сам формат сесії: від логістики залу до того, як ставити запитання й не «вбити» модель гігантським контекстом. Наступного дня Поко́к виходить уже в ролі ключового доповідача з розширеною версією своїх ідей, але саме воркшоп дає рідкісну можливість побачити, як ці ідеї працюють у живому середовищі.
Дві години замість «магічного шоу»: чому формат має значення
Воркшоп позиціоновано як сесію «для справжніх інженерів», які вже пробували писати код з AI, часто користуються такими інструментами щодня й так само часто відчувають фрустрацію. Це не вступна лекція про те, «що таке LLM», і не шоу-демонстрація, де все заздалегідь підготовлено. Формат побудовано так, щоб учасники могли паралельно працювати разом з інструктором.
Тривалість — приблизно дві години. Це важливий компроміс між глибиною й концентрацією: часу достатньо, щоб пройти повний цикл від постановки задачі до перших кроків реалізації, але недостатньо, щоб перетворити подію на виснажливий марафон. Поко́к свідомо не чекає «офіційного» старту за розкладом, коли зал уже заповнений: він починає раніше, щоб не змушувати людей сидіти без діла ще чверть години. Це дрібниця, але вона добре показує, що фокус — на робочому темпі, а не на формальностях.
Ще один принцип — максимально практичний ухил. Короткий вступ про обмеження LLM швидко змінюється на «давайте вже писати код». Теоретичні концепції — «розумна зона» й «тупа зона» моделей, поведінка контексту, сесійні фази — подаються не як абстрактна теорія, а як пояснення того, чому конкретні робочі прийоми виглядають саме так, а не інакше.
Цей підхід добре лягає на цільову аудиторію: інженери, які «вже все це пробували», не хочуть ще однієї загальної розмови про майбутнє AI. Їм потрібен формат, де можна одночасно слухати, дивитися на реальний код і пробувати ті самі кроки у власному середовищі.
Публічний репозиторій як «поле бою»: як організовано практику
Серцем воркшопу стає публічний репозиторій із вправами. Посилання на нього виведено на екран у залі, і учасників прямо закликають клонувати репо й працювати разом з інструктором. Для тих, хто не встиг або не хоче налаштовувати середовище, залишається можливість просто спостерігати за ходом роботи на великому екрані.
У репозиторії лежить приклад реального застосунку — платформи керування курсами під назвою Cadence. Це щось на кшталт CMS для викладачів і студентів, у яку в рамках вправи потрібно додати нову фічу. Такий вибір не випадковий: замість синтетичних «іграшкових» задач учасники працюють із кодовою базою, схожою на те, з чим вони стикаються в повсякденній роботі.
Перша вправа — додати до Cadence механіку гейміфікації, щоб підвищити залученість і утримання студентів. Клієнтський бріф для цієї фічі збережено в корені проєкту у файлі clientbrief.mmd. Це важливий елемент структури: вимоги не «висять у повітрі», а є частиною репозиторію, з яким працює і людина, і AI-агент.
Такий підхід одразу задає кілька рамок.
По-перше, він показує, як виглядає «агент-готова» задача: опис вимог, кодова база, у яку треба інтегрувати зміни, і зрозумілий сценарій роботи.
По-друге, він дозволяє учасникам відчути повний цикл: від читання бріфа до перших змін у коді, а не лише окремий фрагмент на кшталт «згенеруй мені функцію».
По-третє, він робить воркшоп відтворюваним: будь-хто, хто потім відкриє цей репозиторій, зможе пройти ті самі кроки самостійно.
Поко́к підкреслює, що учасники можуть або активно «відбивати» кожен крок у себе на ноутбуці, або просто дивитися. Але сам факт публічного репозиторію й чітко структурованих вправ задає тон: це не лекція, а спільна робота над кодом.
Два зали, один воркшоп: як працює стримінг і асинхронне Q&A
Попит на тему виявився настільки високим, що основний зал заповнився повністю. Щоб не відмовляти частині охочих, організатори відкрили додаткову кімнату — так звану Gilgood room — куди транслюється живе відео з основної сцени. Поко́к прямо звертається до людей у цьому оверфлоу-залі, нагадуючи, що вони так само є частиною сесії.
Така конфігурація створює нетривіальну задачу: як забезпечити інтерактивність, коли аудиторія фізично розділена, а в основному залі й так немає вільних місць? Класичний формат «підніміть руку, ми принесемо мікрофон» тут просто не працює — ні за часом, ні за логістикою, ні за відчуттям справедливості.
Поко́к відверто говорить, що не любить традиційні Q&A-сесії саме через їхню недемократичність: слово отримують найгучніші й найнапористіші, тоді як решта аудиторії лишається статистами. Щоб уникнути цього, воркшоп використовує асинхронний інструмент для запитань — за принципом Slido.
Учасникам пропонують «зайти в асинхрон» — відкрити посилання на Q&A-сервіс, поставити свої запитання й голосувати за чужі. Уже на старті в інтерфейсі з’являється характерне запитання з залу: «Чому ми маємо чекати до 15:45? Зал переповнений, двері зачинені». Поко́к погоджується з емоцією й фактично демонструє, що цей канал справді працює: питання з’являються, читаються й обговорюються в реальному часі.
Такий формат дає кілька важливих переваг.
По-перше, він вирівнює можливості для всіх — як у головному залі, так і в Gilgood room. Неважливо, де ти сидиш і наскільки комфортно тобі говорити в мікрофон: твій голос має ті самі шанси бути почутим, як і в інших.
По-друге, він дозволяє аудиторії самій визначати пріоритети. Голосування за запитання виносить нагору те, що хвилює більшість, а не лише окремих ентузіастів.
По-третє, він не блокує хід воркшопу. Питання можна збирати й сортувати паралельно з основною частиною, а потім повертатися до них у відповідні моменти, не розриваючи структуру сесії.
У результаті воркшоп отримує рідкісне поєднання: живий, динамічний формат із повною залою й одночасно — масштабовану, відносно справедливу систему зворотного зв’язку, яка не ламається при збільшенні аудиторії.
Від «чатиків» до робочих процесів: для кого насправді цей воркшоп
Офіційний опис події чітко визначає цільову аудиторію: інженери, які «готові вийти за межі чат-асистентів і побудувати реальний робочий процес для доставки фіч з автономними кодовими агентами». Це важливе уточнення, яке відрізняє цей воркшоп від багатьох інших заходів про AI.
Більшість розробників уже встигли спробувати щось на кшталт «запитай у моделі, як написати цю функцію» або «згенеруй мені тест». Частина використовує AI-асистентів щодня, але водночас регулярно стикається з розчаруванням: модель «тупить», губиться в довгих сесіях, пропонує дивні рішення або просто перестає бути корисною, коли контекст розростається.
Поко́к прямо запитує зал, хто вже писав код з AI, хто робить це щодня й хто відчував фрустрацію. Руки піднімаються масово. Це не аудиторія новачків, які вперше бачать LLM, а люди, які вже пройшли стадію «вау-ефекту» й тепер хочуть зрозуміти, як перетворити хаотичний досвід у системний інструмент.
Сам воркшоп побудовано так, щоб відповісти саме на це запитання. Замість того, щоб показувати «чарівні» можливості моделі, Поко́к концентрується на обмеженнях — і на тому, як під них підлаштувати робочий процес.
Ключова рамка — ідея «розумної» й «тупої» зон LLM. На початку нової сесії, коли контекст ще невеликий, модель працює найкраще: увага розподіляється ефективно, зв’язки між токенами не перевантажені. Але що більше тексту накопичується в одному вікні контексту, то гіршими стають результати. Поко́к посилається на ідею, запропоновану засновником компанії Human Layer: кожен новий токен — це як нова команда в футбольній лізі, яка додає квадратично більше матчів. У LLM це означає квадратичне зростання кількості відношень уваги.
На практиці це виливається в те, що десь після приблизно 100 тисяч токенів (незалежно від того, чи дозволяє модель мільйонний контекст, чи 200 тисяч) система починає «тупіти». Вона робить дедалі дивніші помилки, гірше тримає в голові деталі й загалом поводиться менш передбачувано. Багато розробників упізнають цю картину зі свого досвіду.
Звідси випливає головний висновок воркшопу: якщо мета — побудувати надійний робочий процес, а не разове демо, то потрібно навчитися розбивати роботу на такі шматки, які поміщаються в «розумну зону» моделі. І це вже не про «задати правильний промпт», а про інженерний дизайн задач.
«Мементо» для LLM: чому контекст краще скидати, ніж стискати
Ще одна ключова ідея, яка проходить через воркшоп, — ставлення до контексту як до чогось радикально крихкого й одночасно повністю керованого. Поко́к порівнює LLM із головним героєм фільму «Memento», який постійно втрачає пам’ять і повертається до базового стану.
У термінах сесії це означає, що кожен раз, коли очищується контекст, модель повертається до того, що задано в системному промпті. Усе, що було в діалозі, зникає. Це не баг, а властивість, яку можна й варто використовувати.
Поко́к показує типовий життєвий цикл однієї сесії:
спочатку — системний промпт, який завжди присутній у контексті й задає базову роль та обмеження моделі;
далі — фаза дослідження, коли агент «обходить» кодову базу, ставить уточнювальні запитання, формує уявлення про задачу;
потім — фаза імплементації, де відбувається власне написання коду;
нарешті — фаза тестування й перевірки, включно з запуском тестів і короткими циклами зворотного зв’язку.
Ключова рекомендація: системний промпт має бути якомога меншим. Якщо в нього одразу «залити» сотні тисяч токенів, сесія почнеться вже в «тупій зоні», ще до того, як модель встигне зробити хоч щось корисне. Поко́к згадує випадки, коли люди намагаються покласти в системний промпт 250 тисяч токенів — і фактично позбавляють модель шансу працювати ефективно.
У цьому контексті він критично ставиться до популярної практики «компактингу» — стискання довгої історії діалогу в коротший підсумковий запис, який потім знову підсовується моделі як частина контексту. Багато розробників люблять цей підхід, бо він створює ілюзію безперервної «пам’яті» агента. Але Поко́к віддає перевагу радикальнішій стратегії: повністю очищувати контекст і повертатися до чистого базового стану.
Аргумент простий: базовий стан завжди однаковий і передбачуваний. Якщо навчитися будувати робочий процес так, щоб кожна сесія могла стартувати «з нуля», маючи лише невеликий системний промпт і обмежений обсяг релевантної інформації, то поведінка моделі стає стабільнішою. Натомість багаторазовий компактинґ створює «шари осаду» — стиснені резюме попередніх кроків, які можуть містити помилки, спотворення або просто зайвий шум.
Щоб тримати цю динаміку під контролем, Поко́к використовує лічильник токенів прямо в середовищі розробки. У статусному рядку він бачить точну кількість токенів, які вже витрачені в поточній сесії, й може оцінити, наскільки близько перебуває до «тупої зони». Він називає цю інформацію «абсолютно необхідною» для кожної сесії кодування з AI: без неї розробник працює всліпу, не розуміючи, чому модель раптом почала поводитися гірше.
Цікаво, що при цьому Поко́к не прив’язує свої методи до конкретної моделі. На воркшопі він використовує Claude Code, але прямо говорить, що описані прийоми працюють із будь-яким LLM. У центрі уваги — не бренд, а архітектура сесії: як розмір промпта, обсяг контексту й структура задачі впливають на якість результату.
Воркшоп як прототип майбутніх процесів розробки
Якщо подивитися на цей воркшоп збоку, він виглядає не лише як навчальна сесія, а й як прототип того, як можуть виглядати командні процеси розробки з AI у найближчі роки.
Публічний репозиторій із вправами нагадує спільний кодовий базис, до якого підключаються як люди, так і агенти. Наявність чітко сформульованого клієнтського бріфа в репо — це крок до того, щоб вимоги були однаково доступні й зрозумілі для всіх учасників процесу, включно з моделлю.
Двогодинний часовий слот із чітким початком і кінцем схожий на «спринт у мініатюрі», де команда (у цьому випадку — аудиторія) проходить через повний цикл: від постановки задачі до перших результатів. Обмеження за часом змушує думати про розмір задачі й те, як її розбити на частини, які модель може «переварити» в межах своєї «розумної зони».
Стримінг в оверфлоу-зал і асинхронне Q&A через Slido-подібний інструмент нагадують розподілені команди, де учасники перебувають у різних часових поясах і просторах, але мають спільний інформаційний канал і механізм пріоритизації запитань.
Нарешті, акцент на очищенні контексту замість безкінечного компактингу — це натяк на те, як можуть еволюціонувати інструменти оркестрації агентів. Замість того, щоб підтримувати одну «вічну» сесію з наростаючим контекстом, майбутні системи, ймовірно, будуть запускати багато коротких, чітко структурованих сесій, кожна з яких вирішує обмежену задачу в межах «розумної зони».
У цьому сенсі воркшоп Поко́ка — не просто навчання, а демонстрація певної філософії: AI-асистована розробка не скасовує класичні інженерні принципи, а, навпаки, робить їх ще важливішими. Розмір задачі, чіткість вимог, структура сесії, дисципліна в роботі з контекстом — усе це стає критичним не лише для людей, а й для агентів.
Висновок: інженерія процесу важливіша за «чарівність» моделі
Дводенний воркшоп Метта Поко́ка показує, що справжня складність AI-асистованої розробки лежить не в тому, щоб змусити модель написати код, а в тому, щоб побудувати навколо неї правильний процес.
Формат події — дві години живої роботи з публічним репозиторієм, стримінгом в оверфлоу-зал і асинхронним Q&A — демонструє, як можна масштабувати навчання й взаємодію, не втрачаючи відчуття залученості. А фокус на «розумній» і «тупій» зонах LLM, мінімальному системному промпті, очищенні контексту й контролі за кількістю токенів показує, що успіх залежить від того, наскільки уважно інженери ставляться до обмежень моделей.
Для розробників, які вже втомилися від хаотичних експериментів із чат-ботами й хочуть побудувати стабільний робочий процес із автономними кодовими агентами, цей воркшоп пропонує не чарівну кнопку, а набір дисциплінованих практик. І саме в цьому, схоже, полягає реальна «новизна» AI-парадигми: не в тому, що вона скасовує старі правила інженерії, а в тому, що змушує дотримуватися їх ще суворіше.