Skip to content
← Усі розділи

Розділ 01

Маніфест

Deep Work Plan (DWP) — це методологія на основі лише markdown для структурованого, автономного виконання роботи AI-агентами програмування. Вона перетворює розмиту мету на придатний до рецензування план — специфікацію — який агент може виконати, призупинити, відновити та відзвітувати про нього, не втрачаючи контексту й не імпровізуючи до неузгоджених результатів.

Глибока робота для агентів

Назва описує практику, яку вона породжує: зосереджене, тривале зусилля на когнітивно вимогливій роботі, що тримається купи завдяки структурі, а не силі волі. Та сама властивість, що робить глибоку роботу цінною для людей — концентрація без відволікань, підтримувана впродовж тривалого горизонту, — це те, що потрібно AI-агенту програмування, аби завершити роботу, яка триває години чи дні. Deep Work Plan надає цю структуру і тим самим перетворює репозиторій на AI-first, пілотовну агентами кодову базу.

Агент без плану поводиться як працівник розумової праці, який ніколи не виділяє час, нічого не занотовує й перемикає контекст на кожне переривання. Deep Work Plan дає агенту еквівалент заблокованого календаря та письмового брифу: окреслений обсяг, чітку послідовність та стійке місце для запису прогресу.

Напрям — це множник

Спроможність AI-агента програмування залежить не стільки від моделі, скільки від якості наданого йому напряму. Спроможна модель, спрямована на неоднозначний запит, посилює неоднозначність; та сама модель, спрямована на точну специфікацію, посилює точність. У міру вдосконалення моделей цей розрив радше зростає, ніж звужується — вузьке місце зміщується вгору за течією, від написання коду до визначення роботи. Релевантна навичка вже не виконання; це напрям.

Це переосмислює, що означає вдало делегувати. Хороше делегування — це не прохання агента про роботу, а визначення роботи достатньо чітко, щоб її можна було виконати правильно: мета, обмеження, контекст, якого агенту інакше бракувало б, та критерії, які вирішують, чи він досяг успіху. Більшість цінності створюється до того, як починається виконання.

Deep Work Plan — це дисципліна виконання цієї роботи вгору за течією у стійкій, повторюваній формі. Її два стовпи — це дві половини хорошого напряму: специфікація окреслює, який вигляд має «правильне», а harness дає агенту контекст та інструменти, щоб цього досягти. Разом вони перетворюють сиру здатність моделі на надійну інженерію — підтримувану впродовж завдання, що триває години, та збережену між агентами, які змінюються між сесіями.

Spec-driven за задумом

Це перший стовп методології, і, як і «harness», його варто визначити прямо.

Що таке spec-driven розробка. У звичайній роботі, керованій промтами, джерелом істини є розмова: ви просите агента про щось, він редагує файли, і єдиним записом наміру є транскрипт чату, який прокручується геть і більше ніколи не переглядається. Spec-driven розробка (SDD) перевертає це. Спершу ви записуєте, що має бути істинним — мету, обсяг, критерії приймання, перевірки, що доводять завершення, — і саме ця написана специфікація, а не розмова, є джерелом істини. Далі агент виконує роботу за специфікацією, а не імпровізує з однорядкового промту.

Як DWP це втілює. У Deep Work Plan план і є специфікацією. Мета стає придатним до рецензування планом; план розкладається на атомарні завдання; кожне завдання несе чіткі критерії приймання та валідаційні gate; а протокол завершення підтверджує роботу за ними. План → завдання → gate → завершення — це SDD, зроблена конкретною та придатною до виконання.

Чому це важливо. Написання специфікації першою окуповується трьома способами: воно зменшує дрейф, бо агента оцінюють за заявленими критеріями, а не за згасаючою памʼяттю про запит; воно робить роботу перевірюваною, бо кожен gate або проходить, або ні; і воно робить роботу відновлюваною, бо специфікація переживає будь-яку окрему сесію чи агента — інший агент може взятися за неї завтра й точно знати, що означає «завершено».

Чим DWP відрізняється. Навколо цієї ідеї сформувався ширший spec-driven рух, зокрема GitHub Spec Kit, Amazon Kiro та Tessl. Ці підходи зазвичай привʼязані до конкретного інструмента чи платформи. DWP свідомо інакший: він незалежний від інструмента та нативний для репозиторію. Специфікація живе в репозиторії як звичайний markdown, тож вона подорожує разом із кодом, а не з продуктом постачальника — і вона безпосередньо поєднується з другим стовпом, адже сама специфікація є частиною harness, який несе репозиторій.

Репозиторій стає harness

Це другий стовп методології, і він заслуговує на пряме визначення — «harness» став навантаженим терміном, і значна частина галузі вживає його, не пояснюючи, що він означає.

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

Що таке harness-інженерія. Більшість команд будують це риштування неявно, усередині єдиного інструмента — конкретного IDE, продукту-агента чи спеціального фреймворку — тож воно працює лише там і зникає тієї миті, коли ви перемикаєте інструменти. Harness-інженерія — це дисципліна свідомого проєктування цього риштування як повноцінного артефакту. Deep Work Plan займає одну тверду позицію щодо того, де воно має жити: не в інструменті, а в самому репозиторії.

Чому репозиторій — правильне місце. Коли harness живе в репозиторії, він подорожує разом із кодом, кожен агент, що відкриває репозиторій, успадковує його, а сам він версіонується, рецензується та поліпшується, як будь-який інший код. DWP встановлює кожну частину harness як конкретний, стійкий артефакт:

Елемент harness Що він надає Куди DWP кладе його у вашому репозиторії
Контекст те, що агенту потрібно знати AGENTS.md, docs/ та README кожного модуля
Інструменти те, що агент може робити скіли, агенти .agents/ та команди dwp-*
Керувальний цикл як просувається робота Deep Work Plan: план → атомарні завдання → gate → завершення
Запобіжники те, що тримає її правильною чіткі критерії приймання та валідаційні gate
Стан як вона переживає переривання плани, чернетки та журнал прогресу .dwp/ у gitignore

Оскільки кожен елемент — це файл у репозиторії, а не функція інструмента, harness портативний за побудовою. Це й є однорядкове твердження, на якому ґрунтується решта методології: сам репозиторій стає harness, тож будь-який агент може пілотувати будь-який репозиторій — без жодного спеціального фреймворку під кожен інструмент.

Чому важливе структуроване автономне виконання

Сучасні AI-агенти програмування спроможні, але неспрямовані. Спрямуйте такого на нетривіальне завдання, і він зазвичай починає негайно редагувати файли, втрачає лік того, що змінив, і видає роботу, яку важко рецензувати й неможливо відновити.

DWP накладає легку структуру, що безпосередньо усуває кожну з цих невдач:

  • Придатні до рецензування завдання — робота розкладається на послідовні одиниці, кожна з чітким обсягом та критеріями приймання.
  • Збережений стан — прогрес записується, тож робота переживає переривання й може бути відновлена між сесіями та агентами.
  • Стандартизована документація — люди й агенти поділяють одну ментальну модель через спільний формат.
  • Портативність між агентами — методологія працює з будь-яким агентом через тонкі адаптери, а не переписування.

Markdown від початку до кінця

DWP визначає структуру, а не програмне забезпечення. Немає середовища виконання для встановлення, немає дерева залежностей і немає привʼязки. План, завдання та робочий журнал — це звичайний markdown, який може прочитати будь-який агент, переглянути будь-яка людина та чисто відстежити будь-яка система контролю версій. Результат — це виконання, яке можна читати, перевіряти й якому можна довіряти.