Технічний контекст
Я тут повністю згоден з формулою brainstorm → spec → plan → implementation. Коли я роблю AI implementation у реальній розробці, я майже ніколи не прошу Claude відразу писати фічу цілком. У цей момент модель ще не розуміє межі завдання, а отже, починає додумувати архітектуру за мене.
Спочатку я використовую його як збирача контексту. Я закидаю мету фічі, шматки поточної архітектури, обмеження, API-контракти, спірні місця і прошу повернути це назад у стислому вигляді: що він зрозумів, чого не вистачає, де ризики. Ось цей крок рятує від половини дивних рішень.
Далі я не йду відразу в код. Я прошу зробити spec: що саме змінюємо, які є non-goals, acceptance criteria, edge cases, які модулі зачепимо. Якщо специфікація виглядає пухкою, нова сесія не допоможе, тому що проблема не у вікні контексту, а в тому, що завдання ще не зібране.
Після цього я прошу розгорнути spec у plan. Не абстрактний план на рівні «зробити backend, потім frontend», а нормальну інженерну розбивку: порядок кроків, залежності, файли, тести, міграції, rollback-ризики. І ось уже з plan я запускаю implementation, зазвичай маленькими шматками.
Нову сесію я відкриваю часто, але не магічно «для генерації коду», а щоб зафіксувати чисту фазу роботи. У нову сесію я передаю вже вичищений spec, plan і потрібний кодовий контекст. Це значно краще, ніж тягнути довгий back-and-forth, де перемішані ідеї, спростування та глухі кути.
Делегування теж працює, але не як заміна мисленню. Я можу попросити Claude окремо зібрати невідомі, окремо запропонувати структуру spec, окремо перевірити план на дірки. Тобто я делегую підзадачі, а не відповідальність за інженерне рішення.
Вплив на бізнес та автоматизацію
На практиці тут три виграші. Перший: менше холостого коду, який потім треба викидати. Другий: простіше оцінювати терміни, тому що plan вже розбитий на реальні кроки. Третій: легше будувати automation with AI в команді, де кілька людей та асистентів працюють над однією фічею.
Виграють команди, у яких дорогий контекст: легасі, інтеграції, нестандартна логіка. Програють ті, хто все ще просить модель «зроби готову систему» одним промптом і потім дивується, чому все розвалюється на рев'ю.
Я у себе в Nahornyi AI Lab вирішую саме такі завдання для клієнтів: розкладаю хаотичну розробку на керований pipeline, де AI automation прискорює випуск, а не плодить нові ризики. Якщо у вас фічі тонуть у контексті, давайте подивимося на ваш процес і зберемо таку AI integration схему, яка реально зніме зайву ручну роботу.