Що робить документ з планом зниження цінності для проєкту розробки програмного забезпечення? У чому різниця між хорошим планом і чудовим? Я постійно розповідаю, що витрачаю 85%+ свого часу та енергії на етапи планування. А що це означає насправді? Це важко пояснити абстрактно; Потрібен конкретний приклад, щоб справді проілюструвати нюанси. Тож я вирішив поділитися хорошим прикладом із сьогоднішнього дня. Це також відповідає на нещодавнє питання, яке я отримав щодо мого підходу. Здається, люди думають, що потрібно робити все в проєкті за один раз. І в моєму підході це правда, але лише для першої версії! Якщо ви вирішите додати нові функції або змінити спосіб роботи, звісно, можна це зробити, коли у вас буде працююча версія 1. І це відбувається так само, як ви створюєте v1: спочатку створюєте дуже детальний план розмітки, а потім перетворюєте його на намистини. Тож я наведу приклад із Cass, моєї програми Coding Agent Session Search, яка є досить складною програмою на Rust, що автоматично виявляє, парсить, зберігає та індексує всі ваші попередні журнали сесій майже з усіх програмних агентів. Він пропонує миттєвий «пошук під час набору» менш ніж за 50 мс у всіх цих журналах і має багато інших корисних функцій. Я вирішив додати функцію до Cass, схожу на функцію, яку я вже маю в MCP Agent Mail і в beads_viewer (bv): можливість експортувати вашу систему як статичний вебсайт, який можна обслуговувати через GitHub Pages. Ви можете побачити приклад BV саме для цього проєкту, який є фінальним результатом процесу планування, який я опишу в цьому дописі: Ця функціональність робить дуже швидким і простим створення та розгортання експортованого сайту за допомогою утиліти gh. Сам сайт зазвичай складається зі sqlite-файлу та великої кількості typescript і wasm, які повністю працюють у браузері, але з дуже хорошою продуктивністю та приємними функціями та стилем, що ви можете побачити на наведеному прикладі. Обмін повідомленнями агента MCP або купою бісерів — це одне, а спільне використання багатьох журналів сесій агента кодування — зовсім інше; ці речі часто наповнені конфіденційною інформацією, ключами API, лайками/інвективами (принаймні моїми!) та іншими матеріалами, які ви точно не захочете розкривати світу. Але GitHub Pages, яким би зручним він не був, працює лише для публічних репозиторій (до речі, мої інструменти також підтримують сторінки Cloudflare, але GH Pages кращий і простіший для цього випадку). То як же впоратися з цими проблемами? Відповідь — це шифрування: користувач спочатку обирає, які кодові агенти включати, які папки проєкту, часовий період тощо, і генерується пакет (зверніть увагу, що цей пакет знаходиться у канонічному форматі, у який Cass внутрішньо конвертує всі повідомлення агента кодування з їхніх оригінальних рідних форматів), а потім користувач надає пароль для шифрування цього набору. Ідея в тому, що хоча репозиторій і веб-сторінка є публічними, усі, крім вас і тих, кому ви даєте пароль, просто побачать поле пароля і не зможуть прочитати жодне повідомлення. Після введення пароля відкривається красивий, чутливий інтерфейс, який дозволяє легко шукати повідомлення майже так само швидко і ефективно, як це робить Касс. А якщо вам справді нема чого приховувати, можна залишити пароль відкритим і зробити все публічним. У будь-якому разі, це дуже складна нова функція з багатьох причин. Експортний майстер сам по собі надзвичайно складний і складний. Але додаткові вимоги до шифрування та безпеки ускладнюють правильне виконання. У будь-якому разі, я попросив Claude Code з Opus 4.5 спочатку вивчити весь відповідний код з мого bv-проекту для реалізації цієї функції, а потім пояснив, чим відповідна функція в Cass має відрізнятися. Потім це створило для мене початковий розріз за планом. Я попросив CC ще раз перевірити код bv, щоб отримати більше інформації про те, як ця функція була реалізована в BV, а потім використати ці знання для розширення та покращення документа плану. Нарешті, я переніс план на ChatGPT Pro у браузері з GPT 5.2 з розширеним логічним рішенням разом із цим вступом до запитів: "Уважно перегляньте весь цей план для мене і продумайте найкращі ревізії щодо кращої архітектури, нових функцій, змін тощо, щоб зробити його кращим, надійнішим/надійнішим, продуктивнішим, більш захопливим/корисним тощо. Для кожної запропонованої зміни дайте мені детальний аналіз і обґрунтування, чому це покращить проєкт разом із зміною стилю git-diff порівняно з оригінальним планом, показаним нижче:» Потім я вставив результати у Claude Code ось так: Добре, тепер інтегруйте ці зміни до існуючого плану знижки; Використовуйте Ultrathink і будьте ретельними. Наприкінці ви можете сказати, з якими змінами ви повністю погоджуєтесь, з якими частково погоджуєтесь, а з якими ні: '''[Вставлений текст #1 +995 рядків]''' Потім я прополоснув і повторив це ще двічі. Це не швидкий процес: останній огляд, який ви можете побачити на скріншоті нижче, зайняв 27 хвилин: Остаточний план знижки на ~3 500 ліній можна побачити тут: Але ще цікавіше побачити правки на GitHub, де можна побачити величезні покращення від версії 2 до версії 3, і як ці покращення тривають аж до кінця: Це зайняло загалом близько 3 годин. Підозрюю, саме тому більшість людей не хочуть займатися таким рівнем планування. Складається враження, що ви мало що робите, бо код не пишеться, але якщо ви все зробите правильно і запустите достатньо агентів у своєму натовпі з Agent Mail, Beads і bv, то код буде написаний настільки швидко, що це з лишком компенсує цю повільну частину. І більше того, код буде дуже хорошим. Повертаючись до історії, я був готовий перетворити план на намистини. Я вже пояснював цей процес в іншому нещодавньому дописі, але суть у тому, щоб використати цей запит із Claude Code: "Добре, тепер прочитай ВЕСЬ PLAN_TO_CREATE_GH_PAGES_WEB_EXPORT_APP.md; будь ласка, візьміть ВСЕ це, розкладіть детальніше і використайте для створення комплексного та детального набору намистин для всього цього з накладанням завдань, підзавдань і структури залежностей, з детальними коментарями, щоб усе було повністю самодостатнім і самозадокументованим (включно з релевантним бекграундом, міркуванням/обґрунтуванням, міркуваннями тощо — усе, що ми хотіли б, щоб наше «майбутнє я» знало про цілі, наміри, процес мислення і те, як це служить загальним цілям Проєкт). Намистини мають бути настільки деталізованими, щоб нам ніколи не довелося звертатися до оригінального документа плану розмітки. Пам'ятайте, що потрібно використовувати ЛИШЕ інструмент 'bd' для створення та модифікації намистин і додавання залежностей. Використовуй Ultrathink.» Потім я просто повторював цей повторний запит у Claude Code: "Перечитайте AGENTS dot Md, щоб це ще було свіжо в пам'яті. Потім прочитайте ВСЮ PLAN_TO_CREATE_GH_PAGES_WEB_EXPORT_APP.md. Використовуйте Ultrathink. Дуже уважно перевіряйте кожну намистину — ви впевнені, що це має сенс? Чи це оптимально? Чи можемо ми щось змінити, щоб система працювала краще для користувачів? Якщо так, оновіть намистини. Набагато простіше і швидше працювати у «плановому просторі» до того, як ми почнемо впроваджувати ці речі! НЕ СПРОЩУЙТЕ ВСЕ! НЕ ВТРАЧАЙТЕ ЖОДНИХ ФУНКЦІЙ ЧИ ФУНКЦІОНАЛЬНОСТІ! Також переконайтеся, що в бісери ми включаємо комплексні юніт-тести та скрипти e2e з чудовим і детальним логуванням, щоб бути впевненими, що все працює ідеально після впровадження. Вкрай важливо, щоб ВСЕ з плану знижки було вбудовано в намистини, щоб нам ніколи не довелося повертатися до плану розмітки і не втрачати важливий контекст, ідеї чи інсайти щодо нових функцій, запланованих і причин, чому ми їх створюємо.» Після приблизно 8-9 раундів він нарешті досягає стабільного стану. Потім я попросив Codex з GPT 5.2 зробити фінальний раунд, використовуючи той самий запит. Кінцевий результат можна побачити за посиланням, наведеним вище. І ось так, друзі, виглядає хороший план. А також як виглядає хороший набір намистин за планом. Ці намистини настільки відшліфовані та деталізовані, що можна механічно випустити велику групу агентів для реалізації за допомогою Agent Mail, Beads і BV, і все вийде майже ідеально без зайвих проблем. Я занадто втомлений, щоб сьогодні ввечері починати цю роботу, але зроблю це завтра і потім поділюся новою функцією, яка, думаю, дуже сподобається користувачам Cass.

Перш ніж витрачати багато жетонів на великий рій агентів на новий проєкт, стара деревообробна максима «Виміряй двічі, ріж раз!» варто переглянути як «Перевіряй намистини N разів, впроваджуй один раз», де N — це фактично стільки, скільки ви можете витримати. Я помітив, що чим частіше ви запускаєте це з Opus 4.5 поспіль у Opus 4.5, тим більше і більше покращень, навіть якщо вони непомітні, ви отримуєте все більше покращень (зверніть увагу, що наступне завдання призначене лише після того, як ви вже перетворили свій початковий план розмітки на намистини за іншим завданням, яке я нещодавно дав у своєму дуже довгому дописі про робочі процеси): "Перечитайте AGENTS dot Md, щоб це ще було свіжо в пам'яті. Дуже уважно перевіряйте кожну намистину — ви впевнені, що це має сенс? Чи це оптимально? Чи можемо ми щось змінити, щоб система працювала краще для користувачів? Якщо так, оновіть намистини. Набагато простіше і швидше працювати у «плановому просторі» до того, як ми почнемо впроваджувати ці речі! НЕ СПРОЩУЙТЕ ВСЕ! НЕ ВТРАЧАЙТЕ ЖОДНИХ ФУНКЦІЙ ЧИ ФУНКЦІОНАЛЬНОСТІ! Також переконайтеся, що до цих бісерів ми додаємо комплексні юніт-тести та скрипти e2e з чудовим і детальним логуванням, щоб бути впевненими, що все працює ідеально після впровадження. Пам'ятайте, що потрібно використовувати ЛИШЕ інструмент 'bd' для створення та модифікації намистин і додавання залежностей до намистин. Використовуй Ultrathink.» Раніше я запускав це лише один-два рази перед початком реалізації, але нещодавно експериментував із запуском 6+ разів, і він постійно вдавав корисні вдосконалення. Якщо він почне знижуватися з точки зору поступових покращень намистин, можна спробувати почати нову сесію CC, починаючи з: "Спочатку дуже уважно прочитайте ВСІ файли AGENTS dot md і README dot md і зрозумійте ВСІ обидва! Потім використовуйте режим агента для дослідження коду, щоб повністю зрозуміти код, технічну архітектуру та призначення проєкту. Використовуй Ultrathink.» А потім додаю той самий запит, як показано вище, але з початком: "Нещодавно ми перетворили файл плану знижки на купу нових намистин. Я хочу, щоб ви дуже ретельно переглянули і проаналізували ці документи, використовуючи 'bd' і 'bv'." Чим складніший і заплутаніший ваш план оцінки, тим актуальнішою стає ця техніка. Якщо у вас є невеликий, тривіальний план і дуже простий проєкт, це, очевидно, перебір. Але в такому разі ти, ймовірно, майже не побачиш поступових приростів/змін з кожним раундом, тож має бути досить очевидно, коли час зупинитися. Просто пам'ятайте: токени планування набагато менше і дешевші за токени реалізації. Навіть дуже великий, складний план розмітки коротший за кілька основних кодових файлів, не кажучи вже про цілий проєкт. І моделі набагато розумніші, коли розмірковують над планом, який дуже детальний і продуманий, але водночас достатньо дрібний, щоб легко вписуватися у контекст (саме це і є ключовим розумом моєї нав'язливої уваги до планування і чому я витратив 80%+ часу на цю частину). І якщо ви покладаєтеся на GPT Pro з Extended Reasoning у веб-додатку для початкового планування, як я наполегливо рекомендую (тобто щоб створити і покращити свій план знижки, який згодом перетворюєш на намистини), то ви фактично отримуєте це на принципі «скільки можете» з Pro-планом, тож скористайтеся цим повністю! Жодна інша модель не може торкнутися Pro в інтернеті, коли він працює з введеннями, які легко вписуються у контекстне вікно. Це справді унікально. Тепер ви все ще можете отримати багато додаткової користі, поєднуючи розумні ідеї з Gemini3 у веб-додатку з увімкненим Deep Think, або з Grok4 Heavy, або Opus 4.5 у веб-додатку, але все одно варто використовувати GPT Pro у вебі як остаточний арбітр того, що брати з якої моделі і як найкраще інтегрувати. І оскільки цей допис міг би бути ще більш комічно довгим, залишаю вам свою пропозицію щодо інтеграції цих конкуруючих планів в єдиний канонічний план «найкраще з усіх світів» з розміткою: "Я попросив 3 конкуруючі LLM зробити те саме, і вони запропонували досить різні плани, які ви можете прочитати нижче. Я хочу, щоб ви ДУЖЕ ретельно проаналізували їхні плани з відкритим розумом і були інтелектуально чесними щодо того, що вони зробили, що краще за ваш план. Потім я хочу, щоб ви запропонували найкращі можливі зміни до вашого плану (просто оновіть існуючий документ для оригінального плану з цими правками), які майстерно і майстерно поєднують «найкраще з усіх світів», створюючи справжню, остаточну, кращу гібридну версію плану, яка найкраще досягає наших заявлених цілей і найкраще працюватиме в реальній практиці для вирішення проблем, з якими ми стикаємося, і наших загальних цілей при цьому забезпечуючи максимальний успіх підприємства настільки, наскільки це можливо; Вам слід надати мені повну серію змін у стилі git-diff до вашого початкового плану, щоб перетворити його на новий, покращений, значно довший і детальний план, який інтегрує найкраще з усіх планів з усіма хорошими ідеями (не обов'язково згадувати, які ідеї взялися з яких моделей у фінальному оновленому плані): " (Чорт забирай, ще один запит для розваги; Я використовую цей варіант для ітеративного покращення існуючого плану зниження): "Уважно перегляньте весь цей план для мене і продумайте найкращі ревізії щодо кращої архітектури, нових функцій, змін тощо, щоб зробити його кращим, надійнішим/надійнішим, продуктивнішим, більш захопливим/корисним тощо. Для кожної запропонованої зміни дайте мені детальний аналіз і обґрунтування, чому це покращить проєкт разом із зміною стилю git-diff порівняно з оригінальним планом, показаним нижче:»

Рівень сатанинської залученості тут... 𖤐⁶⁶⁶𓃶