7 версій ТЗ на 29 розділів — кодом стало 4: нова форма дисципліни в post-AI епосі

23 вересня 1999 року NASA втратило апарат за $327 млн через тиху розбіжність між специфікацією і кодом. Сьогодні таку розбіжність вам генерує агент — швидко, впевнено й тисячу разів на день. Розбір того, чому 29 розділів ТЗ гірші за 4 рядки, з AI-friendly template і шістьма анти-патернами.

Гордий автор додає чергову теку до велетенської вежі специфікації на 29 розділів; за склом — самотні чотири картки коду й машина, що шматує решту, поки клерк годує її сторінками; н

23 вересня 1999 року в центрі управління Лабораторії реактивного руху сиділи люди й чекали на сигнал. Mars Climate Orbiter мав вийти на орбіту Марса — увімкнути двигун, загальмувати, зачепитися за гравітацію планети на висоті 226 кілометрів. Інженери дивилися на екрани. Сигнал не прийшов у розрахований час. Не прийшов і пізніше. Апарат увійшов в атмосферу на висоті 57 кілометрів — утричі нижче — і згорів, як сірник, кинутий у пічку.

Причина була не в зламаному двигуні й не в кривому навігаторі. Дві команди — Lockheed Martin, що писала бортове ПЗ, і навігатори JPL — мали один спільний документ. Software Interface Specification. Узгоджене ТЗ, яке чорним по білому вимагало одиниць СІ: ньютон-секунди. Програма Lockheed мовчки видавала фунт-сили-секунди. Розбіжність — рівно у 4,45 раза. Ніхто не злама́в правило. Просто кодом стало не те, що було в специфікації. Ціна цієї тиші між «написано» і «збудовано» — 327,6 мільйона доларів. За них можна було найняти армію людей, які весь політ робили б рівно одне: звіряли, що в коді стоять ньютони. Не найняли. Дешевше вийшло згоріти.

Я тримаю цю історію в голові щоразу, коли відкриваю власний репозиторій із трьома версіями технічного завдання на двадцять дев'ять розділів. Бо я був тією командою Lockheed. І командою JPL водночас. Я писав специфікацію — і я ж її тихо порушував руками агента. Просто мій Марс коштував дешевше, тому я й дозволяю собі втрачати його регулярніше.

Спекулянт спеки

У мене є антагоніст, і він має обличчя. Я бачу його щоранку в дзеркалі ванної, але назву його окремою людиною, щоб було не так боляче. Це Спекулянт Спеки — він же Архітектор Двадцяти Дев'яти Розділів.

Спекулянт плутає одну річ із іншою, і вся його трагедія в цій підміні: він плутає обсяг специфікації з її якістю. Дозвольте перекласти його хворобу мовою лабораторії, бо там вона має точну назву. Добре ТЗ — це дизайн експерименту: гіпотеза, яку можна спростувати, і процедура, яка це зробить. Спекулянт натомість пише не протокол, а оглядову статтю — рясну, ерудовану, з вичерпним list of references і нульовою методологією. Він пише ТЗ так, як середньовічний чернець переписував Біблію: побожно, рясно, з ілюмінованими полями. Розділ 7: «Архітектурні принципи». Розділ 12: «Філософія обробки помилок». Розділ 19: «Глосарій термінів, які більше ніде в документі не вживаються». Кожен розділ дає йому фізично відчутну дозу контролю. Документ важчає — і Спекулянт почувається інженером. Він не будує космічний апарат. Він пише про космічний апарат настільки докладно, що вже не лишається часу його збудувати, — і називає це етапом проєктування.

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

Проблема в тому, що відчуття контролю і контроль — різні речі, і різницю між ними вимірювали в лабораторії з контрольною групою. Навесні 2025 року дослідницька група METR зробила те, чого Спекулянт уникає все життя: поставила відчуття проти секундоміра й розвела їх по різних колонках. Шістнадцять досвідчених open-source розробників, 246 реальних задач із їхніх власних репозиторіїв, кожен — у середньому з п'ятьма роками досвіду. Половину задач дозволили робити з AI-інструментами, половину — без; рандомізація, як у клінічному випробуванні, де одна група п'є таблетку, а друга — крейду. Перед стартом розробники прогнозували, що AI прискорить їх на 24%. Секундомір показав, що AI сповільнив їх на 19%. А тепер головне, заради чого взагалі тримають контрольну групу: навіть після експерименту, побачивши власні цифри, розробники й далі були певні, що AI прискорив їх на 20%. Не сповільнив. Прискорив. Дані лежали перед ними — вони повірили відчуттю.

Розрив між відчуттям швидкості й фактом — майже сорок відсоткових пунктів. Люди газували на нейтралці, чули рев двигуна й щиро вважали це швидкістю. Найдорожче в цій сцені те, що спідометр був усередині голови, а колеса — зовні, і ніхто не дивився на колеса. Науковець назвав би це чистим placebo speedup: пігулка не діє, але самопочуття поліпшилось, і пацієнт вимагає випустити її в продаж.

Ось хто такий Спекулянт. Його двадцять дев'ять розділів — це той самий рев на нейтралці. Він написав три версії ТЗ і відчуває +20% продуктивності, поки реально стоїть на місці з мінусом. Товщина документа — його тахометр, відірваний від коліс: стрілка в червоній зоні, машина не рухається, водій щасливий.

Чому 29 розділів технічно гірші за 4 рядки

Тут більшість зупиняється на моралі «не пишіть забагато, пишіть по суті» — і це порожня порада, бо її дає кожен, і її ніхто не виконує. Я хочу натомість показати фізику. Бо у post-AI епосі роздуте ТЗ шкодить не естетично. Воно шкодить механічно.

Дослідники зі Стенфорда описали ефект, який назвали «lost in the middle» — загублене в середині. Велика мовна модель тримає увагу на початку контексту й у кінці контексту чіпко, як людина пам'ятає перше й останнє речення промови. А все, що в середині, провалюється: точність відповідей падає на 30% і більше, коли потрібна інформація лежить десь у центрі довгого тексту. Контекст не читається рівномірно. Він читається, як ми читаємо договір про іпотеку — перший абзац, підпис, а двадцять сторінок посередині наосліп. Різниця лише в тому, що в іпотеці посередині ховають комісію банку, а у вашому ТЗ — умову, без якої апарат не долетить.

Тепер накладіть це на двадцять дев'ять розділів. Спекулянт сховав ключову умову — ту, від якої залежить, працює система чи горить, — у розділ 14. Рівно в анатомічну сліпу зону моделі. Він зробив це не зі зла. Він зробив це з ретельності: важлива умова заслуговувала на власний розділ, а власний розділ опинився посередині. Спекулянт власноруч відніс найважливіше речення в єдине місце документа, де його гарантовано не прочитають, — і пишався тим, що виділив йому окрему главу. І агент, генеруючи код, цю умову фізично не побачив — не тому, що дурний, а тому, що так влаштована його увага.

Автор з ніжністю ховає найважливішу сторінку в самісіньку середину товстої теки; за дверима аудитор читає лише верх і низ, а середину викидає; сріб…

Він власноруч відносить найважливіше речення в розділ 14 — єдине місце, де його гарантовано не прочитають, — і пишається, що виділив йому окрему главу. Срібнолуска це вже зрозуміла: розжиріла, вона оселилася рівно в середині стосу, у сліпій зоні «lost in the middle».

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

ПараметрТЗ Спекулянта (29 розділів)ТЗ як контракт (4 рядки)
Що дає авторуВідчуття контролю (+20%, як у METR)Контроль (перевірюваний)
Де ключова умоваРозділ 14 — у сліпій зоні «lost in the middle»Рядок 2 з 4 — у полі уваги
Що бачить агентПочаток і кінець; середину — на 30% гіршеУсе, одночасно
Механізм звірянняВідсутній («я ж усе написав»)Один тест: збудоване = написане
Аналог із 1999-гоSoftware Interface Specification, який усі підписалиSIS + перевірка одиниць перед запуском
РезультатMars Climate OrbiterАпарат на орбіті

Зверніть увагу на останній рядок таблиці. Команди Mars Climate Orbiter мали ідеальний документ. Двадцять дев'ять розділів специфікації, якщо хочете. Узгоджений усіма. Проблема була не в тому, що ТЗ було погане. Проблема була в тому, що ніхто не звірив код проти ТЗ перед тим, як апарат полетів. Висновок слідчої комісії NASA — це найважливіше речення в усьому цьому тексті, і я процитую дослівно:

«The problem here was not the error; it was the failure of NASA's systems engineering, and the checks and balances in our processes, to detect the error.»
— Едвард Вейлер, заступник адміністратора NASA з космічної науки

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

Хто заробляє на вашому розділі 14

Але чому Спекулянт взагалі існує в такій кількості? Це не особистий вибір і не слабкість характеру — це раціональна відповідь на систему стимулів, яка нагороджує товщину документа, бо замовник бачить розділи, а не орбіту. Навколо цієї сліпоти годується трійця, і в кожного — своя біла халата серйозності. Вендор AI-інструментів продає вам «governance platform» на двісті функцій: він — той колега, що показує не результат, а товстий апарат із кнопками, і ціна обґрунтована рівно тим, що пульт виглядає складним, хоча вимірює радість, а не орбіту. Консультант зі «стратегії впровадження AI» виставляє рахунок за тижні узгодження розділу 7 з розділом 12 — він публікує по статті на кожне засідання, нарощує h-індекс приписок і жодного разу не ставить контрольну групу, бо контрольна група показала б, що без нього було б так само. Корпоративний software-інтегратор виграє тендер товщиною пропозиції: procurement навчений ставити знак рівності між обсягом і серйозністю, як рецензент, що пропускає статтю на сорок сторінок, бо на двох вона виглядала б несолідно. Усі троє продають вам p-value свого існування — і жоден не дозволить його перевірити.

Хто платить за цю гру — соло-фаундер із чотириденним строком і стартап-команда з трьох людей, у якої немає ні юриста для розбору двадцяти дев'яти розділів, ні часу на ілюзію контролю. Вони або копіюють корпоративний шаблон (і тонуть у розділі 14), або не пишуть ТЗ узагалі (і тонуть раніше). Spec bloat — не помилка системи. Це її продукт.

Контраргумент, який варто почути

Тут чесно зупинитися. Не всі двадцять дев'ять розділів — неврози. Є реальний клас систем, де чотири рядки — це смертний вирок, а не дисципліна. Розподілені мікросервіси з п'ятьма командами в різних часових поясах. Медичне ПЗ під FDA 21 CFR Part 11, де кожна вимога має бути трасована до конкретного рядка коду й підписана двома інженерами. Авіоніка, де формальна верифікація — це не бюрократія, а єдиний спосіб довести відсутність помилок. Для цих контекстів розгорнута специфікація — не спека заради спеки, а реальний механізм координації між людьми, які не можуть читати думки одне одного, і регулятором, якому потрібен аудиторський слід.

Але ось що цей контраргумент не пояснює: переважна більшість проєктів, де сьогодні пишуть двадцятидев'ятирозділові ТЗ, — це не авіоніка й не FDA-regulated software. Це MVP SaaS-продукт, яким будуть користуватися двісті людей. Це внутрішній дашборд. Це скрипт автоматизації, якому жити три місяці. Тут товста специфікація грає роль, яку науковець знає під ім'ям cargo cult: повторити зовнішні ритуали справжньої дисципліни — трасування вимог, формальну верифікацію, підпис двох інженерів — у надії, що від самого обряду полетить літак. Авіоніка пише сто розділів, бо ціна одного багу — труни. Ваш дашборд пише сто розділів, бо так писала авіоніка. Перше — методологія. Друге — імітація методології, що сплутала строгість із товщиною й вирішила: якщо вдягнути білий халат, аналіз стане валідним. Складні системи справді потребують більше структури. Але структура — це не обсяг, рецензент — це не вахтер на вході, і глосарій у розділі 19 не врятував жодної орбіти.

Шість анти-патернів Спекулянта

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

#Анти-патернЯк звучить виправданняЩо насправді відбувається
1Том замість тези«Я детально все розписав»+20% відчуття при −19% користі (METR)
2Похорон у середині«Ключова умова в розділі 14»Сліпа зона «lost in the middle», −30% уваги
3Спека без звіряння«Я ж усе задокументував»Софт Lockheed: фунти замість ньютонів
4Сирий промт без контракту«Агент розумний, сам розбереться»19,7% згенерованих залежностей — неіснуючі
5Версіонування неврозу«Це вже третя ітерація ТЗ»Три рефакторинги тривоги, нуль рішень
6Глянець замість продуманості«Виглядає professional»«Looks right but doesn't quite work»

Затримаюся на четвертому, бо він із усіх найстрашніший — і найсмішніший. Коли ви кидаєте агенту сирий промт без специфікації дозволених залежностей, він допише імпорти сам. Звучить як зручність. Дослідження Spracklen та колег (USENIX Security 2025) проаналізувало 576 тисяч згенерованих фрагментів коду від шістнадцяти моделей і виявило: 19,7% запропонованих залежностей — пакети, яких не існує. Понад двісті тисяч унікальних фейкових імен, вигаданих із повітря з абсолютною впевненістю інтонації. Агент не каже «я не знаю такої бібліотеки» — він каже «import» і ставить крапку, бо сумнів не входить у його граматику.

І це не теорія. Дослідник Bar Lanyado з Lasso Security помітив, що моделі вперто галюцинують пакет huggingface-cli (справжній ставиться інакше). Він зареєстрував на PyPI порожню пустушку з цим іменем — просто подивитися. За три місяці її завантажили понад 30 тисяч разів. Серед тих, хто проковтнув галюцинацію й вставив її собі в README, була Alibaba. Уявіть масштаб іронії: корпорація на сотні мільярдів інсталює пакет, який існує лише тому, що нейромережа його наснила, а добра людина вирішила сон матеріалізувати.

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

А тепер про шостий анти-патерн — глянець, — бо він наймиліший і тому найпідступніший. «Looks right but doesn't quite work» — це не недбалість агента. Це p-hacked результат у чистому вигляді: гарний графік, переконлива підпис під рисунком, і нуль відтворюваності під капотом. Науковець бачив таких статей тисячі — ту, де висновок сяє, бо автор тихо викинув три невдалі прогони й залишив один щасливий. Агент робить рівно це: генерує код, що компілюється, проходить демо й валиться на першому ребрі, якого не було в показовій вибірці. Глянець — це специфікація, відполірована до стану, коли її приємно показати борду й неможливо перевірити тестом. Вона publishable. Вона тільки не reproducible.

Брукс знав це за 50 років до агентів

Тут хочеться видихнути й сказати: «Ну це AI все зламав, раніше було простіше». Брехня. Просто раніше Марс падав повільніше — і ми встигали відвести очі, поки він горів.

Оригінальний CHAOS Report групи Standish за 1994 рік — задовго до будь-якого агента — порахував долю софтверних проєктів. Успішних: 16,2%. Скасованих до завершення: 31,1%. Решта 52,7% доповзли до фінішу з перевищенням бюджету в середньому на 189%. А тепер головне: причина номер один, через яку проєкти йшли під ніж у цьому звіті, — «Incomplete Requirements», неповні вимоги, 13,1%. Не криві програмісти. Не слабке залізо. Дірява специфікація. Це історично головна причина смерті проєктів — за десятиліття до того, як хтось вимовив слово «промт». Ми вбивали власні проєкти діркою в ТЗ ще тоді, коли AI не вмів навіть галюцинувати пакети — просто робили це повільно й вручну, з гідністю.

А ще раніше, у 1986 році, Фред Брукс в есеї «No Silver Bullet» (увійшов до ювілейного видання «Міфічного людино-місяця») написав речення, яке варто витатуювати на зворотному боці кожної клавіатури:

«The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is so difficult as establishing the detailed technical requirements...»

Найважче в побудові системи — вирішити, що саме будувати. Брукс сказав це за чотири десятиліття до агентів. Структурне програмування обіцяло зробити написання коду тривіальним — і оголило, що складність у рішенні «що». ООП обіцяло те саме — і оголило те саме. Аджайл, фреймворки, low-code — кожна хвиля здирала шар штукатурки й показувала ту саму несучу стіну: вирішити, що будувати, — і є вся робота. Сорок років індустрія купувала дедалі дорожчі інструменти, щоб не дивитися на цю стіну, і дивувалася, чому будинок щоразу падає в тому самому місці.

AI здер останній шар. Коли написання коду делеговане агенту приблизно на 80% — а саме цю цифру Карпаті назвав на сцені Sequoia в 2026-му, додавши, що сам не набрав власноруч жодного рядка з грудня 2025-го, — рішення «що будувати» перестає бути частиною роботи людини. Воно стає єдиною роботою людини. Уся складність, яку сорок років ховали в синтаксисі, спливла в одне питання — і виявилося, що це питання дизайну експерименту, а не набору тексту. Дисципліна ТЗ у post-AI епосі — це не написати ідеальний документ; це мати один безжальний механізм, що звіряє збудоване проти написаного. Те, чого не було в NASA 23 вересня 1999 року.

Чоловік, який поховав власне дитя

Іронію цієї епохи найкраще втілює одна людина у двох сценах із різницею рівно в рік.

Сцена перша. Лютий 2025-го. Андрей Карпаті відкидається в кріслі, диктує код голосом через застосунок для транскрипції, майже не торкаючись клавіатури, і пише фразу, яка миттєво розлітається мільйонами переглядів: «повністю віддатися вайбам... забути, що код узагалі існує». Народжується термін vibe coding. Хаос благословенний з самого олімпу.

Сцена друга. Той самий чоловік, рік по тому, на сцені Sequoia AI Ascent 2026. Він каже, що ніколи не почувався більше «позаду» як програміст, і оголошує вайб-кодинг застарілим. Натомість — «agentic engineering»: ти не пишеш код напряму 99% часу, ти оркеструєш агентів і виконуєш роль нагляду. Vibe coding піднімає підлогу — будь-хто може зробити будь-що. Agentic engineering утримує стелю якості — тобі не дозволено вносити вразливості заради вайбу, ти, як і раніше, відповідаєш за свій софт.

Той самий чоловік, що благословив відсутність правил, через рік власноруч підписав їй вирок і назвав «наглядом» рівно те, що раніше зневажав. Він не зрадив ідею — він просто першим побачив рахунок, який вона виставляє, і вирішив сплатити його словом «дисципліна». А індустрія вчинила, як завжди: канонізувала дисципліну заднім числом і почала продавати правила назад. 2 вересня 2025-го GitHub відкрив Spec Kit — інструмент, де специфікація прямо названа «контрактом того, як код має поводитися, і джерелом істини, яким агенти генерують, тестують і валідують код». Спершу ейфорія від відсутності правил. Потім інституції, що торгують правилами в гарній обгортці. ТЗ повернулося — тільки тепер як виконуваний інтерфейс до машини й з прайс-листом.

Інструмент: AI-friendly ТЗ, яке вміщається в увагу

Досить діагнозу. Ось скальпель, яким я тепер ріжу власні двадцять дев'ять розділів до чотирьох. Це шаблон специфікації, спроєктований під фізику уваги моделі — щоб сигнал жив на початку й у кінці, а не вмирав посередині.

БлокПитання, на яке відповідаєЧому саме тут
1. Намір (1 речення)Що ця система робить і для кого?Початок контексту — зона чіпкої уваги
2. Жорсткі межіДозволені залежності; чого робити НЕ можнаФаєрвол проти галюцинованих пакетів (19,7%)
3. Контракт поведінкиВхід → вихід, у конкретних одиницях«Ньютони, не фунти» — буквально
4. Критерій звірянняЯкий тест доводить, що збудоване = написане?Кінець контексту — друга зона уваги; те, чого бракувало NASA

Чотири блоки. Не двадцять дев'ять. Усе, що не вмістилося, — не вирізане з ТЗ, а викрите як те, чим воно й було: ваша тривога, перевдягнена в розділ. Блок 4 — не опційний. Якщо ви не можете сформулювати тест, який доведе відповідність коду специфікації, у вас немає специфікації. У вас є есей про наміри. А есей про наміри згорів на висоті 57 кілометрів — разом із автором, який до останнього був певен, що все задокументував.

Як виглядає механізм звіряння, коли він не абстракція

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

Візьмімо Блок 3 із шаблону вище: «при вході суми у фунт-силах функція повертає тягу в ньютонах». Спекулянт написав би на це абзац філософії одиниць у розділі 8. Звіряння — це інше. Це передумова: який мінімальний експеримент завалить код, якщо код бреше? Відповідь міститься в одному рядку:

assert convert_thrust(1.0) == 4.45  # фунт-сила → ньютон; інакше — Марс

Розберімо, чому ці двадцять символів сильніші за двадцять дев'ять розділів. По-перше, це falsifiable: є рівно одне число, яке або зійдеться, або ні; третього стану — «загалом схоже» — не існує, а саме в третьому стані живе Спекулянт. По-друге, це контрольна група у формі коду: софт Lockheed віддав би тут 1.0 замість 4.45, тест почервонів би на першій же секунді, і дев'ять місяців польоту не знадобилися б, щоб дізнатися ціну розбіжності. По-третє, цей рядок стоїть у кінці — у другій зоні чіпкої уваги моделі, а не в анатомічній сліпій зоні розділу 14. Агент, генеруючи, бачить критерій останнім — і пише код під нього, а не повз нього.

Ось операційне правило, до якого все зводиться. Перш ніж відкрити IDE, напишіть не специфікацію, а тест, який її спростує. Якщо тест написати не виходить — ви ще не знаєте, що будуєте. І це не привід додати тридцятий розділ. Це привід зупинитися й сформулювати гіпотезу, яку взагалі можна програти. Двадцять дев'ять розділів — це спосіб ніколи не дійти до рядка, на якому стає видно, що король без штанів. Один assert доводить це за мілісекунду — і саме тому Спекулянт інстинктивно його не пише.

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

Фінал: усі мають свій Марс

Повернімося в той зал JPL 23 вересня 1999 року. Інженери дивляться на екран, де мав з'явитися сигнал, і він не з'являється. Спеку погодили всі. Усі двадцять дев'ять розділів, якщо вони були. Документ був бездоганний. Просто кодом стало щось інше, і між цими двома фактами не стояв жоден механізм, який би крикнув «стоп» до запуску.

Post-AI епоха не дала вам цей механізм. Вона забрала у вас час на його відсутність. Раніше розрив між «написано» і «збудовано» накопичувався місяцями, і його ще можна було випадково помітити на код-рев'ю. Тепер агент генерує цей розрив швидко, впевнено й тисячу разів на день — вставляє неіснуючий пакет, ігнорує умову з розділу 14, віддає фунти замість ньютонів і повідомляє вам, що завдання виконано. Looks right. Doesn't quite work. Апарат уже в атмосфері, а в логах — зелена галочка.

Дисципліна — це не товщина вашого ТЗ. Спекулянт Спеки помер на тому ж пагорбі, що й Mars Climate Orbiter: з ідеальним документом, який ніхто не звірив. На його надгробку висічуть двадцять дев'ять розділів дрібним шрифтом, і ніхто не дочитає до чотирнадцятого. Дисципліна — це чотири рядки, які машина здатна втримати в очах одночасно, і один безжальний тест, що ловить розрив до того, як апарат полетить.

На голому сталевому столі під лампою лежать рівно чотири картки коду; позаду машина дошматовує вежу на 29 розділів у замети конфеті, які згрібає пр…

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

У вас зараз відкритий репозиторій із трьома версіями ТЗ. Не перечитуйте їх — це лише ще раз погладить відчуття контролю на +20%. Зробіть натомість єдиний експеримент, від якого Спекулянт усе життя тікав: знайдіть найважливішу умову й спитайте, чи є рядок коду, що почервоніє, коли її порушать. Якщо такого рядка немає — у вас не специфікація, а гіпотеза без процедури спростування, тобто настрій. А настрій згоряє на висоті 57 кілометрів незалежно від того, у скількох розділах він був викладений. Питання тільки, на якій висоті ви це помітите — і чи лишиться ще час дивитися на колеса, а не на спідометр.

Питання та відповіді

Що таке ефект «lost in the middle» і чому він робить роздуте ТЗ небезпечним?

«Lost in the middle» — явище, описане дослідниками Стенфорду: велика мовна модель утримує увагу на початку і в кінці контексту, тоді як точність відповідей для інформації в середині падає на 30% і більше. Якщо ключова умова потрапляє в розділ 14 з 29, вона опиняється в анатомічній сліпій зоні агента — він фізично не помітить її, не зі злого умислу, а за архітектурою уваги. Практичний висновок: будь-який критичний параметр має стояти на початку або в кінці специфікації, а не в «логічно правильному» центральному розділі.

Дослідження METR показало, що AI сповільнив досвідчених розробників на 19% — але вони й далі вірили в прискорення на 20%. Як таке можливо?

METR протестувала 16 open-source розробників на 246 реальних задачах із рандомізацією, як у клінічному випробуванні. AI-інструменти фактично збільшили час виконання на 19%, проте навіть після того, як розробники побачили власні цифри, вони щиро вірили, що прискорились на 20%. Це «placebo speedup»: рев двигуна сприймається як швидкість, хоча колеса стоять. Для автора ТЗ це означає, що відчуття продуктивності від написання нових розділів — ненадійний вимірювач; єдиний надійний — збіг між написаним і збудованим.

Що таке slopsquatting і який він має стосунок до специфікації залежностей?

Slopsquatting — атака, яка використовує передбачуваність галюцинацій AI: дослідження Spracklen et al. (USENIX Security 2025) показало, що 19,7% залежностей із 576 000 проаналізованих фрагментів коду — неіснуючі пакети, причому 43% галюцинованих імен відтворюються стабільно в усіх 10 прогонах одного промта. Зловмисник реєструє ці «сни машини» на PyPI заздалегідь: Bar Lanyado з Lasso Security зареєстрував порожній пакет huggingface-cli і за три місяці отримав 30 000 завантажень, серед яких — Alibaba. Список дозволених залежностей у ТЗ — це не бюрократія, а буквальний фаєрвол проти цього вектору атаки.

Що означає «4-рядкове ТЗ» і чи підходить воно для складних систем?

Чотири блоки — не кількість рядків, а архітектурний принцип: намір (1 речення), жорсткі межі (дозволені залежності і заборони), контракт поведінки (вхід → вихід у конкретних одиницях — «ньютони, не фунти») і критерій звіряння (тест, що доведе збіг). Для авіоніки під DO-178C, медичного ПЗ під FDA 21 CFR Part 11 або розподілених мікросервісів з кількома командами — повна трасованість вимог реально потрібна. Але автор фіксує: переважна більшість проєктів із роздутими ТЗ — це MVP SaaS або внутрішні дашборди, де 29 розділів є cargo cult, а не методологією.

Що Карпаті назвав «agentic engineering» і чому він відмовився від vibe coding?

У лютому 2025-го Карпаті популяризував vibe coding — «повністю віддатися вайбам, забути, що код існує». Рік по тому на Sequoia AI Ascent 2026 він оголосив цей підхід застарілим: коли агент виконує ~80% написання коду, людина переходить у режим нагляду й оркестрування — «agentic engineering». Ключова зміна: vibe coding підіймає підлогу (будь-хто може щось зробити), але знімає відповідальність; agentic engineering повертає її — людина більше не може вносити вразливості «заради вайбу» і залишається відповідальною за якість того, що генерує машина.

Коментарі

Лише для залогінених читачів — щоб лишалось людським, а не болотом ботів.