Як писати ТЗ, яке зрозуміє і людина, і агент: шаблон + 6 анти-патернів

Аркуш креслення лягає на дошку о сьомій ранку. Архітектор намалював вікно: ось контур, ось ширина, ось висота отвору. А висоти підвіконня від чистої підлоги — немає. Просто немає. Прораб тицяє в порожнє місце пальцем, наче воно може проявитися, набирає архітектора — гудки. Ще раз — гудки. Бетон уже сходить із міксера, мулярі стоять, кожна хвилина простою тікає в копійку. І прораб робить те єдине, що йому лишилось: ставить підвіконня на висоту, яку двадцять років вважав «нормальною». Дев’ятсот міліметрів. Як завжди.

За два тижні приїде замовник, стане навпроти, і його обличчя витягнеться. Вікно ріже краєвид рівно по лінії горизонту — низько, не так, геть не так, як він малював у голові. І він скаже фразу, яку прораб чув сто разів і почує ще сто: «Я ж мав на увазі інакше».

Цей текст — про ціну оцього «мав на увазі». І перше число тут не про вікна. За дослідженням PlanGrid і FMI, яке опитало майже 600 будівельних керівників, неоптимальна робота — переробки, пошук загубленої інформації та залагодження конфліктів — з’їдає близько 177 мільярдів доларів на рік лише в США (PlanGrid + FMI, «Construction Disconnected», 2018). І коли в тому ж дослідженні запитали, звідки береться переробка, відповідь виявилася не про матеріали й не про лінощі: 52% усієї переробки у світі спричинено поганими даними й непорозумінням — тобто прогалиною між тим, що було в документах, і тим, що автор тримав у голові й не записав (Autodesk / FMI report).

Більш як половина переробки — не помилка виконавця. Це місце, де мали написати й не написали.

Запам’ятайте цю половину. Вона ще вистрелить — у несподіваному місці.

Бо ця історія не про будівництво. Вона про те, що з 2024 року ту саму прогалину — між написаним і задуманим — ми почали масово передавати не прорабам, а машинам. І машина, на відміну від прораба, не набирає номер, щоб уточнити. Вона не чує гудків. Вона просто ставить підвіконня — і йде далі.

Делегування без права на здогад

Ця сцена не про криве підвіконня. Вона про механізм, який можна назвати «здоровим глуздом виконавця» — мовчазну впевненість, що той, кому ми дали завдання, доповнить пропущене так, як доповнили б ми самі. Прораб двадцять років бачив, на якій висоті люди люблять підвіконня. Його здогад має непоганий шанс збігтися з вашим. Це не магія — це спільний контекст: ви обидва люди, обидва живете в кімнатах з вікнами, обидва маєте тіло заввишки приблизно метр сімдесят.

А тепер заберіть спільний контекст. Дайте те саме завдання сутності, яка ніколи не стояла біля вікна, не має тіла, не знає, що таке «нормальна висота» — бо в неї немає поняття «нормально». Є лише розподіл імовірностей над усіма висотами, які траплялися в текстах, на яких її навчили. Це і є AI-агент. І коли ваше технічне завдання має прогалину, агент її не відчуває як прогалину. Він бачить розвилку — і впевнено заходить в один із коридорів. Найчастіше не в той.

Ось де спотикаються навіть досвідчені. Ми звикли, що недомовку рятує перепит. Між людьми це справді так: дайте колезі сирий бриф — і він закидає вас уточненнями ще до того, як почне. Але класичний агент у режимі виконання за замовчуванням не перепитує. Він налаштований доводити справу до результату, а не зупинятися на кожній двозначності. Тож кожна прогалина для нього — не сигнал «спитай», а тиха команда «вирішуй сам». І він вирішує: мовчки, впевнено, не на вашу користь.

Розберу це через дві оптики — будівельну (бо там прогалину в кресленні рахують у доларах уже сто років) і когнітивну (бо є дослідження, які показують, як саме ламається виконавець під вагою інструкцій). А тоді віддам вам шаблон, бо комусь із вас завтра здавати бриф агентові, і я хочу, щоб ви здали його так, щоб не переробляти. Теза-лезо: добре ТЗ — це не опис того, чого ви хочете, а специфікація памʼяті для виконавця, який нічого про вас не памʼятає й нічого не здогадається.

Назву це прямо: ТЗ-як-памʼять. Не документ, не бриф, не «розкажи, що треба». Памʼять. Те, чим виконавець думає замість вас, поки вас немає в кімнаті.

Чому це стало гострим саме зараз

Технічні завдання писали завжди. Чому про це варто говорити в 2026-му, а не в 2006-му?

Бо змінився виконавець. До 2023 року ТЗ читала людина, і людина закривала прогалини здогадом — погано, дорого (ті самі 177 мільярдів), але закривала. З 2024-го по конвеєр пішли AI-агенти, які пишуть код, верстають лендінги, складають аналітику, готують контент. Зсув не косметичний: за словами партнерів Y Combinator, у чверті стартапів зимового набору 2025 року 95% рядків коду згенерував штучний інтелект (TechCrunch, березень 2025). Тобто в кожному четвертому новому продукті майже весь код написала не людина за ТЗ, а машина за чиїмось брифом.

І тут вилазить друга цифра, структурна. Дослідники з лабораторії Sky Computing Lab у Берклі зібрали понад 1600 трас виконання багатоагентних систем, а 150 із них прискіпливо розібрали вручну силами шести експертів — і побудували першу таксономію провалів таких систем, MAST. Збої вони розклали на три великі категорії, і найбільша з них — не «дурна модель» і не «складна задача». Це проблеми системного дизайну й специфікації: близько 44% усіх збоїв — неоднозначність ролей, нечіткі визначення задач, пропущені обмеження (arXiv 2503.13657; MAST, UC Berkeley). Ще третина припадає на неузгодженість між агентами, ще чверть — на провали перевірки. Інакше кажучи: найбільший окремий клас провалів агента — це провал технічного завдання, а не виконавця.

Тепер прочитайте два числа поруч. 52% будівельної переробки — від поганих даних і непорозуміння в документах. ~44% збоїв агентів, найбільша категорія, — від дірок у системному дизайні й специфікації. Різні століття, різні виконавці, різні методики виміру. Та сама хвороба: виконавець ламається не там, де задача складна, а там, де завдання неповне. (Чесне застереження: це дві різні галузі, виміряні різними методами, — збіг не доводить спільної причини. Але коли в двох настільки несхожих світах головний винуватець той самий, варто бодай запідозрити, що проблема не у виконавцеві.)

Гостро стало тому, що раніше прогалину в ТЗ оплачував повільний дорогий здогад людини, а тепер її оплачує швидкий масштабований здогад машини. Машина помиляється дешевше за раз — і в тисячу разів частіше.

Чому агент не може зробити те, що робить прораб

Прораб, наткнувшись на прогалину, має три ходи: подзвонити, згадати схожий випадок або поставити «як завжди». Агент має лише третій — і навіть його робить наосліп.

Причина — у тому, як виконавець ламається під вагою інструкцій. Тут є несподівано точне дослідження під назвою «прокляття інструкцій» (curse of instructions). Команда побудувала бенчмарк ManyIFEval — завдання, у які впаковано до десяти перевірюваних інструкцій одночасно — і виміряла, як падає здатність моделі виконати всі інструкції разом. На наборах із багатьох інструкцій картина жорстка: GPT-4o дотягує до повного набору в середньому лише в 15% випадків, Claude 3.5 Sonnet — у 44%, хоча кожну окрему інструкцію поодинці обидві моделі виконують у 85–90% (Curse of Instructions, OpenReview). І падіння не випадкове: успіх на всьому наборі приблизно дорівнює успіху на одній інструкції, піднесеному до степеня їхньої кількості. Експоненційний обвал.

Перекладаю з академічної на людську. Якщо ви напишете в ТЗ десяток рівноцінних вимог суцільним списком, агент із пристойною імовірністю зросить якусь — і ви не дізнаєтеся, котру, поки не побачите результат. Це не недбалість моделі. Це математика уваги: кожна додана вимога — додатковий множник, менший за одиницю, і добуток невблаганно повзе до нуля. Та сама структура, що в прораба: дайте йому усний перелік із п’ятнадцяти дрібниць «між іншим, не забудь» — і він забуде. Різниця лише в тому, що прораб переб’є вас на третій дрібниці й попросить записати, а агент кивне на всі п’ятнадцять і піде.

Є друга половина цього механізму, не менш важлива за першу. Прогалину можна не лише пропустити — її можна заповнити чужим. Коли агентові бракує вашої інформації, він не лишає порожнечу: він підставляє найімовірніший варіант із усього, що бачив під час навчання. Не вашу цільову аудиторію, а «середню» цільову аудиторію інтернету. Не вашу валюту, а долар, бо доларів у текстах більше. Не ваш тон, а той вилизаний корпоративний голос, яким написано більшість лендінгів світу. Прогалина в ТЗ — це не нуль, який видно. Це місце, куди тихо заливається усереднене сміття чужих рішень, і ви помітите його, лише коли результат вийде дивно безликим. «Чому воно таке загальне?» — бо ви не сказали, яким воно має бути конкретно, і агент дописав за вас найімовірніше.

Звідси головне правило памʼяті-для-агента: завдання — це не список побажань, а структура з пріоритетами, де критичне відділене від бажаного, а «ніколи» прописане так само явно, як «зроби». І де кожне порожнє місце ви лишили порожнім свідомо — бо знаєте, що в нього заллється усереднене, і вас це влаштовує.

Шаблон: шість опор доброго ТЗ

Тепер конкретика, бо без неї це просто гарна теорія. Коли GitHub проаналізував понад 2500 файлів-конфігурацій для агентів (agents.md, CLAUDE.md тощо) у відкритих репозиторіях, виявилося, що найкорисніші завдання покривають шість зон — і це працює далеко за межами коду (GitHub Blog: уроки з 2500+ репозиторіїв). Я переклав ці шість зон з мови розробників на мову будь-якого завдання — лендінг, аналітика, текст, дослідження.

Опора	Що це для коду	Що це для будь-якого завдання	Питання-перевірка
Команди	Точні команди запуску з прапорцями (npm test, не «прогони тести»)	Чим саме перевірити результат, якими інструментами/даними	«Як виконавець дізнається, що готово?»
Перевірка	Який фреймворк, де лежать тести, очікуване покриття	Критерій приймання: що = «зроблено правильно»	«За яким фактом я скажу так/ні?»
Структура	Де код, де тести, де доки	Де лежить контекст, у якому форматі результат	«Куди це покласти і в якому вигляді?»
Стиль	Конвенції коду + приклади	Зразок гарного й поганого результату	«На що це має бути схоже / не схоже?»
Процес	Git-workflow, як комітити	Етапи, точки звірки, що робити при сумніві	«Що робити, коли впреться в розвилку?»
Межі	Файли, яких не торкатися; «ніколи не коміть секрети»	Червоні лінії: чого не робити ніколи	«Що зруйнує все, навіть якщо решта ідеальна?»

Зверніть увагу на останній рядок. У дослідженні GitHub найчастішим корисним обмеженням у завданнях верхнього рівня виявилось саме «ніколи не коміть секрети» — тобто явно прописана межа, а не побажання. Виконавцеві треба знати не лише куди йти, а й де урвище. Прораб урвище бачить очима. Агент — лише якщо ви його намалювали.

Уявіть це на собі, бо ви це робили. Ви відкриваєте чат з агентом увечері, вам треба лендінг до завтра, і пишете: «Зроби односторінковий лендінг для нашого застосунку. Сучасний, чистий, щоб конвертив. Текст придумай сам, головне — щоб гарно». Натискаєте Enter і йдете заварити чай. Тепер прокрутіть це повідомлення через шість опор. Команди? Немає — ви не сказали, чим перевірити «конвертить». Перевірка? Немає критерію, ви впізнаєте провал лише оком. Структура? Не сказано, куди класти, в якому стеку, які секції. Стиль? «Сучасний» і «гарно» — два прикметники, нуль зразків. Процес? Жодного «спитай, якщо застрягнеш». Межі? Порожньо — а отже, агент може вигадати про продукт що завгодно, бо ви не заборонили вигадувати. Шість опор, шість дірок. Ви повернетеся з чаєм до бездоганного на вигляд лендінгу — про неіснуючі функції, з вигаданими цифрами, у тому самому безликому корпоративному голосі, бо порожнечу заповнило усереднене. І скажете машині те саме, що замовник сказав прорабу: «Я ж мав на увазі інакше».

Шаблон тримається на трьох рівнях обмежень, які я раджу виписувати окремими блоками: завжди (роби так за замовчуванням), спершу спитай (тут зупинись і уточни) і ніколи (червона лінія). Це той самий механізм, що рятує прораба: не «здогадайся про висоту підвіконня», а «висота 900 мм; якщо креслення суперечать — стоп, дзвони; нижче 800 не став ніколи».

Шість анти-патернів: як ТЗ провалює саме себе

Тепер — діагностика. Шість способів зіпсувати завдання. Перевірте свій останній бриф проти цього списку.

1. Туман замість завдання. Найпоширеніший і найдорожчий. «Зроби сучасний лендінг», «напиши гарний текст», «проаналізуй клієнтів». Дослідники прямо кажуть: більшість файлів-завдань провалюються тому, що надто розпливчасті (O’Reilly Radar). «Сучасний» — це проти чого? «Гарний» — за чиїм смаком? Для людини туман — запрошення до діалогу. Для агента туман — дозвіл піти в найдешевшу для нього інтерпретацію. Лікування: замініть кожен прикметник на перевірюване число або зразок.

2. Десять вимог суцільним списком. Пам’ятаєте прокляття інструкцій? Багато рівноцінних пунктів суцільним потоком — і модель губить частину. Анти-патерн не в тому, що вимог багато, а в тому, що вони не структуровані за пріоритетом. Лікування: розбийте на «критично / бажано / якщо лишиться час», винесіть «ніколи» окремо, дробіть монолітний бриф на модульні підзадачі.

3. Імпліцитні припущення. Те саме підвіконня. Ви «само собою» знаєте, що сайт має відкриватися на телефоні, що валюта — гривня, що цільова — українці. Агент не знає нічого «само собою». Кожне ваше мовчазне припущення — це розвилка, на якій він кине монетку. Лікування: випишіть усе, що здається «очевидним». Очевидне для вас — невидиме для нього.

4. Завдання без критерію приймання. ТЗ описує, що зробити, але не описує, як зрозуміти, що зроблено правильно. Без критерію приймання і ви, і агент впізнаєте провал лише постфактум — коли замовник дивиться на вікно по лінії горизонту. Лікування: на кожну вимогу — речення «це готово, коли…».

5. Контекст без ієрархії. Зворотний бік туману: автор вивалює на агента сто сторінок документації без структури, і той тоне. Той самий O’Reilly називає це «занадто довгий контекст без узагальнення» — завалити завдання сирими даними працює так само погано, як і недодати (O’Reilly Radar). Увага виконавця — ресурс скінченний, що в людини, що в машини. Лікування: не «ось усе, розберись», а «головне — тут, деталі — за посиланням, ось ієрархія».

6. ТЗ як одноразовий постріл. Останній і найтонший. Завдання написане раз і закам’яніле — а виконавець помилився, ви виправили в чаті, але в саме завдання правку не повернули. Наступного разу агент наступить на ті самі граблі, бо його памʼять — це ТЗ, а ТЗ не оновили. Лікування: кожна виявлена прогалина повертається в текст завдання. ТЗ живе, не висічене в граніті.

А може, просто потрібні розумніші моделі?

Тут чесний опонент скаже: зачекай. Усе це — тимчасова проблема. Моделі 2024 року не вміли уточнювати, ламались на десяти інструкціях. Моделі 2026-го вже перепитують, тримають мільйонні контексти, самі добудовують пропущене. Може, дисципліна ТЗ — це милиця на період, поки агенти дурні, і за два роки вона стане непотрібна, як стало непотрібним вручну керувати памʼяттю в сучасних мовах програмування?

Аргумент сильний, і частину його визнаю: так, моделі вже краще перепитують, і так, поріг терпимості до туману росте. Але є структурна межа, яку не зсунути потужністю. Прокляття інструкцій — не баг конкретної моделі, а властивість будь-якого виконавця зі скінченною увагою: добуток імовірностей, менших за одиницю, падає експоненційно, скільки б параметрів ви не додали. А специфікаційна категорія в MAST — це частка причини, яка не залежить від розуму агента, бо стосується інформації, якої в завданні фізично немає. Розумніша модель краще здогадається, чого ви хотіли. Але здогад — це й є та рулетка, яку добре ТЗ має прибрати. Розумний агент із туманним ТЗ — це геніальний прораб, якому ви все одно не дали висоту підвіконня: він поставить його красивіше, ніж посередній, але так само не туди.

Що довело б, що я не маю рації? Якби з’явились дані, що частка специфікаційних провалів падає швидше за зростання потужності моделей — тобто що нові агенти стабільно правильно вгадують пропущене в ТЗ, а не просто роблять охайніше неправильне. Поки що дані кажуть протилежне: чим більше ми делегуємо агентам, тим дорожче коштує кожна прогалина в завданні, бо вона множиться на масштаб. Дисципліна ТЗ — не милиця перехідного періоду. Це нова базова грамотність, як уміння формулювати пошуковий запит стало грамотністю двадцять років тому.

Прийом, який ловить прогалину до бетону

Повертаюся до прораба з аркушем о сьомій ранку, але вже з іншого боку.

Двадцяте століття навчило інженерів, що креслення без розмірів — не креслення, а малюнок. Що специфікація — професійний документ із критеріями приймання, допусками й червоними лініями, а не записка «зроби красиво». Будівництво заплатило за цей урок мільярдами переробок і вибудувало навколо нього цілу культуру: нормоконтроль, авторський нагляд, обов’язкові розміри на кожному вузлі. Прогалину в кресленні там навчилися бачити як дефект — не виконавця, а документа.

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

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

І ось той прийом, заради якого варто було дочитати. Усі радять «пишіть детальніше, додавайте контекст». Це напівправда — пам’ятаєте анти-патерн №5, контекст без ієрархії. Справжня порада коротша й точніша, і її називають серйозні практики спеціфікації для агентів: попросіть агента перш ніж виконувати, переказати завдання своїми словами й окремо виписати кожне припущення, яке він мусив зробити сам — позначивши його, скажімо, тегом [ПРИПУЩЕННЯ: …] (O’Reilly Radar; freeCodeCamp). Не «зроби», а спершу «скажи, що ти зрозумів, і де ти за мене вирішив». Цей переказ — найточніше дзеркало прогалин, яке існує. Агент покаже вам ваші ж імпліцитні припущення вголос, на кожній розвилці назве коридор, у який збирався піти. Це той дзвінок, якого прораб не зміг зробити архітектору о сьомій ранку, — тільки тепер дзвонить виконавець, безплатно, до того, як замішано бетон.

Архітектор так і не передзвонив. Але цього разу прораб, перш ніж кивнути міксеру, поклав аркуш на стіл і сказав уголос: «Отже, я зрозумів так — вікно на цій стіні; висота підвіконня не вказана, [ПРИПУЩЕННЯ: ставлю дев’ятсот, бо це моє звичне]». І хтось у кімнаті нарешті встиг сказати одне коротке слово, яке коштує дешевше за всі 177 мільярдів разом узяті: «Стоп».

Найдешевший дзвінок у будь-якому проєкті — той, що лунає до бетону. Ваш агент готовий його зробити. Лишилось написати ТЗ так, щоб йому було про що дзвонити.

---

Розкриття партнерства: Dnister — партнер NeuroDrift; згадки практики наведено як ілюстрацію до тези, а не як рекламну пропозицію.