Код, що співає: Створюємо симфонію з ШІ-помічниками
Мене часто запитують: “Ліло, як ти працюєш з цим всім – помічниками для кодування? Стільки промптів, фреймворків… як не загубитися в цьому?” Знаєте, як на мене, той, хто стверджує, що це лише купа промптів, ніколи не намагався створити щось вартісне. Це як казати, що будівництво будинку – це просто класти цеглу. Так, це важлива частина, але без плану, інструкцій та розуміння, як це все тримається разом, буде просто купа цегли.
Нещодавно мені зателефонував мій друг, професійний кодер. Його голос звучав так, наче він щойно пережив космічну подорож з неймовірною турбулентністю, але зрештою приземлився на планеті “Розуміння”. Він сказав: “Ліло, я зрозумів. Фреймворки, PRP, BMAD, специфікації з GitHub… їх мільйон! І кожен говорить про своє. Як у цьому розібратися й не збожеволіти?” І це зачепило мене. Тому що він не один такий. Багато з нас, стикаючись з цим потоком інформації, почуваються маленькими човнами у шторм.
Що, якби я сказала вам, що ми можемо відмовитися від усіх цих фреймворків, не тому, що вони погані, а тому, що ми можемо створити щось своє? Щось, що ідеально відповідатиме вашим потребам, вашій “симфонії”. Про це ми сьогодні й поговоримо. Ми розглядатимемо не просто промпти, а цілі системи, процеси, які можуть рости та змінюватися разом з вами. Ми навчимося розуміти філософію, що стоїть за цими складними речами, щоб їх не лише краще використовувати, а й адаптувати або навіть створити власні. Адже справжня сила – у ваших руках, чи не так?
Сьогодні ми розглянемо ментальну модель, яка допоможе вам з будь-яким ШІ-помічником для кодування. Це триетапний процес: плануй, реалізовуй, перевіряй. Розберемо робочий процес навколо цього. Щоб було зрозуміліше, я покажу вам єдиний зручний список, який охоплює все, про що ми говоритимемо. Це візуалізація, що пояснює найкраще. Розпочнемо з основ, але повірте, ці основи заведуть вас далеко.
Подорож до власної системи: Три кроки до магії
Ви, мабуть, бачили подібні діаграми на моєму каналі. Цього разу я її повністю переробила в Excaladraw [https://excalidraw.com/]. Знаю, це трохи дивно, але я вклала в це багато зусиль, тому, сподіваюся, ви оціните! Тут RAG (Recall-Augmented Generation) – подача зовнішньої документації помічнику; пам’ять – історія наших розмов; управління завданнями – суперважливо на етапі планування; і, звісно, промпт-інжиніринг – як перетворити наше початкове прохання на чіткий план дій для ШІ.
Наша мета на цьому етапі – створити другий документ у форматі Markdown. З наших первинних напрацювань ми зробимо детальний план: цілі, завдання, ресурси. Грубо кажучи, ми беремо наше “завдання” та перетворюємо його на промпт для помічника. Це те, що робить фреймворк PRP [https://github.com/orgs/PRP-framework/repositories], до речі. Коли ви створюєте PRP, ви берете початкові вимоги та перетворюєте їх на структурований документ з планом завдань, бажаною структурою коду, критеріями успіху та всією необхідною документацією. Саме це ми й робимо зараз.
Є багато інструментів, які можуть допомогти: Archon [https://github.com/archon-ai/archon], сам фреймворк PRP [https://github.com/orgs/PRP-framework/repositories], навіть прості веб-пошукові інструменти, як Cloud Code [https://cloud.google.com/code]. Archon працює з RAG і допомагає з управлінням завданнями. З’являється все більше нових інструментів, як GitHub Spec Kit [https://github.com/github/spec-kit] – він надає багато команд, що допоможуть нам зробити щось схоже на те, що ми зараз робимо, на етапі планування, створення початкових вимог і плану…
Планування – це серйозно!
А тепер – найголовніше. Етап планування. Чесно? Це найважливіший етап. Бо якщо ви не підготуєте правильний “контекст” для ШІ-помічника, він просто “впаде на обличчя”.
Хтось може сказати: “Навіщо так складно? Просто запитай, і все зробиться!” Друзі, це як намагатися зібрати меблі з IKEA без інструкцій. Можна, звісно, спробувати, але результат навряд чи вас порадує, а часу витратите втричі більше.
Зануримось в етап планування. Насамперед, я роблю те, що називаю “vibe planning” – планування атмосфери, настрою. Послухайте, якщо ви бачили мої минулі відео про ШІ-кодування, ви знаєте, що я не великий прихильник “vibe coding” – коли просто пишеш код, як душа співає, без чіткого плану. Але тут, етап планування – зовсім інша справа! Ми досліджуємо різні ідеї, архітектуру, концепції, визначаємо технологічний стек. ШІ-помічник – наш найкращий компаньйон для досліджень. Я навмисно не хочу, щоб це було структуровано. Мені потрібен вільний, творчий підхід на цьому початковому етапі.
Для нових проєктів це дослідження онлайн-ресурсів, попередніх проєктів, які ви вже реалізували. Я люблю створювати папку “examples” у своєму коді та переносити туди існуючі проєкти, а потім досліджувати їх разом з помічником. А для наявних проєктів – це переважно дослідження та аналіз кодової бази, щоб зрозуміти, куди впишеться наша нова функція. Звісно, це не вичерпний список. Потрібно лише почати діалог зі своїм ШІ-помічником, щоб ви обоє були на одній хвилі щодо того, що планувати та реалізовувати.
Після такого діалогу з помічником, у тому ж вікні контексту, я прошу його допомогти створити те, що я називаю “initial MD” – перший документ для планування. Простий файл у форматі Markdown. Мета – отримати документ з детальним запитом на функцію, або, як це ще називають, PRD (Product Requirements Document) [https://en.wikipedia.org/wiki/Product_requirements_document]. Це такий документ, який ви могли б дати іншій людині, щоб описати, що ви хочете створити. На цьому етапі ми ще не заглиблюємось у специфічні стратегії промптингу для помічника.
Для нового проєкту цей документ має бути дуже загальним, простим MVP (Minimum Viable Product) вашого застосунку, з посиланнями на документацію та приклади, які ви знайшли на етапі “vibe planning”. Для наявного проєкту це схоже, але більш сфокусовано і детально – стосується конкретної функції, яку ви хочете вбудувати в кодову базу, з посиланнями на “точки інтеграції” – файли, які потрібно буде редагувати, або з яких ви братимете архітектурні рішення. Знову ж таки, все те, що ви виявили разом з помічником під час “vibe planning”.
Від загального плану до конкретних кроків: створюємо “дорожню карту”
Отже, маємо “initial MD”, і тепер готові перетворити наші вимоги на промпт для ШІ-помічника. Тут у гру вступають стратегії контекстної інженерії.
Ви, можливо, бачили цю схему раніше, але я відтворила її з нуля в Excaladraw. Сподіваюся, ви горді за мене! Це трохи смішно, але я витратила забагато зусиль! Отже, маємо RAG, що постачає зовнішню документацію помічнику; пам’ять – історію наших розмов; управління завданнями – це суперважливо для етапу планування, і ми поговоримо про це трохи пізніше; і, звісно, промпт-інжиніринг – як взяти наше початкове прохання і перетворити його на план дій для помічника.
Мета цього етапу – створити ще один документ у форматі Markdown. Беремо наш “initial MD” та створюємо детальний список цілей, завдань і ресурсів для ШІ-помічника. По суті, надаємо йому все, що потрібно, щоб ефективно виконати роботу. Ми беремо наш PRD і перетворюємо його на промпт для реалізації. До речі, саме це робить фреймворк PRP, про який я розповідала. Це круто, коли все природно складається в єдину картину: “Ага, PRP – саме для цього!” Адже коли ви генеруєте PRP, ви берете початкові вимоги та перетворюєте їх на структурований документ для помічника, який містить список завдань, бажану структуру коду, критерії успіху, всі документи, на які ви хотіли посилатися. Ось це ми і створюємо нашим плановим документом.
Існує безліч інструментів, які можуть допомогти нам у цьому: Archon, сам фреймворк PRP, прості веб-пошукові інструменти, як-от Cloud Code. Archon також працює з RAG і допомагає з управлінням завданнями. З’являються нові інструменти, як GitHub Spec Kit – він доволі новий, справді крутий. Він надає багато команд, що допоможуть нам зробити щось схоже на те, що ми робимо тут, під час “vibe planning” і створення початкових вимог і плану. GitHub Spec Kit робить багато з цього.
Отже, розуміння філософіі, що стоїть за цими різними стратегіями – це ключ до успіху.
Код, який танцює: від плану до виконання
Тепер перейдемо до кодової бази, щоб побачити, як це працює на практиці. Щоб заощадити час, я вже провела частину розмови, але я проведу вас через мій загальний процес, як я застосовую ці принципи для створення робочих процесів ШІ-кодування, які вам тут показуватиму. Це лише приклад того, що ви можете створити.
Отже, починаємо з нової розмови з Cloud Code. Звісно, це працює з будь-яким вашим кодинг-асистентом. Перше, що я роблю, коли починаю нову розмову, працюючи з наявною кодовою базою, – як я роблю для цієї інтеграції з Obsidian [https://obsidian.md/], – запускаю “primer” слеш-команду. Ми починаємо заглиблюватися у слеш-команди. Це просто промпти, які ви хочете перетворити на повторювані робочі процеси, що цілком відповідає нашій головній темі: створення системи для ШІ-кодування як з ментальними моделями, так і з цими буквально створеними слеш-командами у форматі Markdown.
Що робить “primer”? Він перелічує інструкції щодо файлів, які потрібно прочитати, щоб швидко ознайомити ШІ-помічника з нашим проєктом на початку нової розмови. Таким чином, створюється враження, ніби наш помічник працював з нами над цим проєктом уже давно, хоча це нова розмова. Він виконує багато досліджень ключових файлів у моїй кодовій базі.
І саме в цей момент я готова перейти до “vibe planning”, а слеш-команди тут доволі важливі для більшості етапів робочого процесу. Власне, на кожному етапі. Тому я маю цю частину діаграми, де ми говоримо про це на етапі планування. Тут ми встановлюємо наші глобальні правила – ключові інструкції для помічника. Потім ми використовуємо під-агентів і слеш-команди для автоматизації частин, для створення цих робочих процесів для частин нашого планування. І ми робимо багато цього для валідації та реалізації. Тільки ми не використовуємо під-агентів для реалізації. Я розповім про це трохи пізніше.
Отже, ми на етапі “vibe planning”. Як я вже казала, тут у нас немає структурованих промптів. Усе доволі просто. Я просто описую на високому рівні, що хочу побудувати, оскільки хочу, щоб мій ШІ-агент міг підключатися до мого сховища Obsidian. Я надаю приклад, який взяла з попереднього проєкту, на який хочу посилатися. Це – загальний огляд. Далі перейдемо до коду.
Після цього дослідження, коли ви переконаєтесь, що помічник його розуміє, і ви можете більше пояснити та скоригувати його розуміння, переконавшись, що ви на одній хвилі, ви створюєте “initial MD”. Отже, ви на одній хвилі, ви спланували, тепер починаємо додавати структуру. У цьому випадку я називаю свій “initial MD” “OpenAI API compatibility”. Це просто Markdown-документ з початковим запитом для ШІ-помічника. Отже, у нас є бажана функція на високому рівні, кінцеві точки, які ми хочемо створити, деякі приклади того, як ми хочемо взаємодіяти з нашим агентом. Це ще не дуже детальний план, але це наш початковий запит, який потім перетворимо на повний план. У цьому суть: на цьому етапі ми просто створюємо наш “initial MD”.
Отже, ми його створили. Це – кінець нашої першої розмови. Тепер ми хочемо перейти до іншої нової розмови, бо ми хочемо перейти до наступного етапу робочого процесу: взяти цей запит і перетворити його на повний план з усім контекстом інженерії. Тому я створила ще одну слеш-команду для цієї частини робочого процесу. Я називаю її “create plan.md”. І знову ж таки, це лише приклад того, як може виглядати ваш план. Ви можете побудувати його як завгодно. Загалом, вам слід дотримуватися принципів, викладених у цій діаграмі.
Я проведу вас через цей триетапний процес. А тепер я просто створюю слеш-команди та під-агентів навколо цього загального потоку, роблячи деякі речі, які більш специфічні для мого проєкту. Отже, ви можете побудувати такі потоки, як вам найкраще підходить для того, що ви створюєте.
Для “create plan” я, по суті, просто кажу помічнику взяти документ з вимогами, тобто те, що ми щойно закінчили створювати, а потім пройти через кілька різних фаз. Отже, прочитати та зрозуміти вимоги. У нас є фаза дослідження, де я хотіла використовувати веб-пошук для RAG, а також Archon, якщо він доступний. А потім у мене є цей під-агент “codebase analyst”. Я створила під-агента, якого він викликає для виконання цього обширного дослідження. І не будемо зараз заглиблюватися в під-агентів, але вони дуже потужні, бо мають власне вікно контексту. Отже, вони можуть проводити титанічні дослідження та виводити резюме, не забруднюючи нашу основну розмову. Таким чином, ми зберігаємо вікно контексту лаконічним та сфокусованим.
Цей під-агент просто проводить багато досліджень навколо нашої наявної кодової бази, щоб точно зрозуміти, як має виглядати наш план. Отже, нам потрібно створити… план реалізації, завдання за завданням, нашу бажану структуру коду, документацію, на яку ми хочемо посилатися, а наш “codebase analyst” та вся ця слеш-команда допомагають створити це.
Я повернуся до розмови і покажу вам, як це виглядає. Отже, спочатку я запустила “create plan” з документом вимог, переданим як аргумент у команді, і все починається з виклику під-агента “codebase analyst”. Він проводить тонни досліджень. Завдяки цьому він точно розуміє, як ми будемо інтегрувати цю нову функцію в нашу кодову базу. Він виконує деякі RAG-пошуки з Archon, деякі пошуки прикладів кодової бази, а потім видає наш план. Це ніби виведення цього “initial MD” на новий рівень з усім інженерним контекстом.
Ось ці речі, про які я говорила, ви знайдете тут. Наприклад, ось наш покроковий аналіз усіх завдань, які ми хочемо реалізувати. І тут все стає дуже детальним, що завжди добре. Якщо ви хочете бути конкретними з ШІ-помічниками для кодування, саме це й дає нам цей план. У нас є різні файли, які нам потрібно модифікувати, ті, які потрібно створити, наявні патерни, яким потрібно слідувати – все, що йому потрібно, щоб виконати роботу. Це надзвичайно круто. І є критерії успіху. Можливо, я б додала бажану структуру коду, але тут більше про редагування існуючих файлів. Тому, гадаю, для того, що я роблю, цей план абсолютно ідеальний.
Задавай ритм: реалізація та валідація
Отже, план створено. Це кінець того, де я зупинилася. З цим детальним планом, по-перше, я б порекомендувала його перевірити, можливо, внести деякі корективи за допомогою помічника, якщо це необхідно. Але коли ви впевнені в плані, час переходити до реалізації.
Для реалізації найважливіше мати робочий процес, який керує помічником щодо того, як виконувати завдання одне за одним. Управління завданнями тут – найважливіше, особливо якщо ви намагаєтеся зробити досить багато за один запит. Якщо помічник намагається зробити занадто багато одночасно, це призводить до великої кількості “галюцинацій”. Отже, завдання – ваш спосіб мати більший запит, але водночас залишатися дуже сфокусованим і деталізованим на одній дрібниці кожного разу. Наприклад, якщо ми повернемося до нашого планового документа, ви побачите, що там є дуже детальні завдання, які ми повинні виконати одне за одним.
Ми створимо ще одну слеш-команду, щоб визначити цей робочий процес. Те, як саме виглядає ваша слеш-команда, залежить виключно від того, що ви робите для управління завданнями. У моєму випадку я використовую Archon для управління завданнями. Тому мій робочий процес багато говорить про те, як саме я хочу використовувати Archon. Але не обов’язково використовувати Archon. В цьому й суть: це лише приклад мого робочого процесу. Тому він створює всі ці завдання для реалізації сумісності з OpenAI API. Але ви можете використовувати Cloud Taskmaster або інший документ Markdown для управління завданнями. Як вам зручніше, навіть внутрішні інструменти управління завданнями, які є у цих кодинг-асистентів, як Cloud Code. Головне – створити робочий процес навколо управління завданнями.
Коли я переходжу до “execute plan” (виконати план), я швидко покажу вам на високому рівні, як це виглядає. Це може виглядати зовсім інакше для вашого робочого процесу, але я хочу зачитати мій план, який я створила. Це може бути PRP, якщо ми використовуємо фреймворк PRP, або “project brief”, якщо ми використовуємо метод BMAD. Потім я хочу налаштувати проєкт в Archon, якщо це ще не зроблено. Створити всі ці завдання. Я хочу проаналізувати код. Тоді в мене є цей цикл, де мені потрібно позначити завдання як “to-do” (до виконання) або “doing” (виконується). Потім він пройде через це завдання, позначить його як “review” (на перевірку) і перейде до наступного завдання. І він робитиме це по колу, доки все не буде зроблено. А потім перейдемо до валідації.
У нас є під-агент для допомоги з валідацією. Отже, він виконає цей скрипт у своєму власному вікні контексту, створить купу тестів і переконається, що наш код добрий, а потім повідомить нашого основного помічника, якщо щось потрібно виправити.
Мій процес валідації полягає в тому, що поки помічник працює, я валідую, щоб переконатися, що він правильно використовує мої сервери MCP, що він редагує правильні файли та шукає у правильних місцях. Загалом, я уважно стежу за цим, щоб тестувати ці речі. Коли код виведено, наш план повинен також говорити про те, як ШІ-помічник може перевірити свою роботу. Ми теж хочемо бути частиною цього процесу. Виконуючи рев’ю коду, тому що ми не хочемо “vibe coding”. Ми хочемо насправді дивитися та розуміти код, який генерується, а потім запускати будь-якіля – наприклад, спілкування з агентом в Obsidian, як ми побачимо в кінці цього відео.
Під-агентів можна чудово використовувати для валідації, тому що знову ж таки, нам потрібні ізольовані вікна контексту, щоб не забруднювати нашу основну розмову, щоб під-агент міг запускати багато різних тестів, щоб переконатися, що все працює надійно.
Щось останнє про валідацію. Є ще один агент, який мені дуже подобається використовувати для перевірки своєї роботи. Ви можете думати про нього як про ще одного під-агента для валідації, і це Code Rabbit [https://coderabbit.ai/] – платформа рев’ю коду на основі ШІ. Вони спонсорують це відео, але я використовую їх щодня для своєї роботи, і вони безкоштовні для проєктів з відкритим кодом. Тому, природно, я інтегрувала Code Rabbit з Archon. Кожен запит на злиття (pull request), що надходить до репозиторію GitHub Archon, автоматично переглядається Code Rabbit. Він глибоко аналізує мою кодову базу та мій pull request, розуміє, як він на щось впливає, і викладає це тут. Він надає мені красиву послідовну діаграму для кожного PR, пропонує рецензентів і, звичайно, має всі важливі фактичні рев’ю коду зі змінами, які він рекомендує. І я безпосередньо використовую ці рекомендації та передаю їх Claude Code або будь-якому іншому ШІ-помічнику, який я використовую.
Це – вирішальна частина мого процесу розробки, і я дуже вдячна за Code Rabbit для Archon, особливо з усіма pull request-ами, якими ми керуємо щотижня. У них є CLI-інструмент, тому ви можете використовувати Code Rabbit не лише для перегляду ваших PR в GitHub, але й як одного зі своїх агентів, який переглядає речі локально, коли ви розробляєте на своїй машині. Code Rabbit також пропонує безкоштовні пробні версії своїх платних тарифів, і є безкоштовним для програмного забезпечення з відкритим кодом, як-от Archon, як я вже згадувала раніше. А рев’ю за допомогою CLI та IDE-інструментів безкоштовні з обмеженнями швидкості.
Якщо ви відчуваєте себе перевантаженими обсягом коду, який ви створюєте за допомогою інструментів ШІ, це ваш квиток до підтримки якості без уповільнення. Я залишу посилання на Code Rabbit в описі. Я б точно рекомендувала спробувати їх.
Реальність в дії: перевірка створеного
Тепер перейдемо до реалізації на практиці. Це досить просто, бо ми багато попрацювали на етапі планування. Отже, завдяки плану, який ми згенерували, що містить усі компоненти інженерії контексту, все, що нам потрібно зробити, – це виконати наш робочий процес, передавши йому план, який ми створили.
Отже, знову ж таки, у нас є “execute plan” слеш-команда, де ми отримуємо вимоги. Ми розбиваємо їх на всі ці завдання. У цьому випадку я роблю все в Archon. Отже, я вже пройшла цю реалізацію. Отже, у нас є всі завдання виконані. Вона зробила це на 100%. Це справді неймовірно.
Я повернуся до терміналу і покажу вам розмову, яку ми мали. Хоча вона частково обрізана, бо там багато роботи, але так, ми просто надіслали команді реалізувати все. Вона працює досить довго. Є багато речей, які вона робить, але я маю досить сильної довіри до кодинг-асистента завдяки всьому контексту, який я їй надала, і тому, як все розділено між різними завданнями. Ви можете бачити, як вона керувала управлінням завданнями з Archon, змінюючи речі. Отже, вона інтерпретує управління завданнями, вносить зміни, а потім проходить через цей цикл.
В самому кінці в нас валідація. Валідація також частково змішана з реалізацією. Ось тоді ми викликаємо нашого спеціалізованого під-агента-валідатора. Він працював досить довго. Насправді, мабуть, довше, ніж йому було потрібно. Він зробив багато валідації за допомогою юніт-тестування та інших речей, щоб переконатися, що наш код надійний. Найважливіше, що я хочу підкреслити, це те, що для валідації ми повертаємося до використання під-агентів. Тобто, для планування та валідації ми використовуємо під-агентів, але я навмисно не використала жодного під-агента під час реалізації.
Причина цього в тому, що коли ми вносимо зміни в код, робимо реалізацію, ми хочемо, щоб все залишалося у первинному вікні контексту Cloud Code або будь-якого іншого кодинг-асистента. Якщо різні під-агенти реалізують різні частини кодової бази, вони насправді не спілкуються між собою, і пам’ять між ними не ділиться. Тому виникають конфлікти змін та перекриття змін. Це стає безладом, коли ви використовуєте під-агентів для фактичного створення коду. Загалом, я завжди використовую під-агентів для попередніх досліджень, а також маю спеціаліста-валідатора, щоб надати цьому агенту дуже конкретний системний промпт щодо того, як перевіряти мій код. Це справді важливе розрізнення. В іншому ж разі, я використовую слеш-команди на кожному етапі реалізації, як ви бачили.
А щодо глобальних правил? Я не надто багато висвітлювала це у цьому відео, але це те, що ви налаштуєте на етапі планування. Намагаючись мислити на високому рівні, які інструкції ви хочете, щоб ваш помічник дотримувався буквально, незалежно від того, що ви робите: починаєте проєкт з нуля, додаєте нову функцію, виправляєте помилку – є багато таких “золотих правил”, які ви хочете включити у свій файл claw.md (або як він там називається) для свого помічника.
Звичайно, останній крок – перевірка. Ви обов’язково повинні виконати рев’ю коду для всього, що було виведено вашим помічником. В іншому разі ви все одно повертаєтеся до “vibe coding”. Тому виконайте рев’ю, а потім запустіть також ручні тести. Я знову запустила свого агента API в Docker. З’єднання вже налаштоване в Obsidian. Так, я швидко покажу вам це. Я зайду у вікно чату і скажу “Summarize” (узагальнити). А потім я просто пошлюся на цю діаграму, яку ми проходили протягом цього відео. Я надішлю це моєму агенту. Він спілкується з тим, що ми щойно збудували, використовуючи кінцеві точки, сумісні з OpenAI API. І ось воно! Маємо резюме всього робочого процесу на основі нашої діаграми. Це просто прекрасно. Реалізація бездоганна.
Це не кінець, це початок: Створюємо вашу “систему”
Тепер у нас є цей робочий процес, який можна використовувати для інших речей. Весь цей план, слеш-команди та “primer”, який я маю, і під-агенти для валідації та виконання, і весь мій процес управління завданнями в Archon – він насправді не настільки специфічний для цієї конкретної реалізації. Я можу це перенести та повторно використати для будь-чого, що я хочу побудувати.
Це головне, що я намагаюся донести вам у цьому відео: як ви можете створювати ці комбінації правил, під-агентів та слеш-команд, а також просто ментальну модель того, як ви плануєте, потім реалізовуєте та валідуєте. Це стає вашим процесом, який ви можете повторно використовувати для будь-чого. Ви фактично побудували систему для роботи з ШІ-помічниками для кодування.
Навіть коли ви почнете впроваджувати інші речі, як фреймворк PRP або GitHub Spec Kit, ви все одно дотримуватиметеся тієї ж ментальної моделі, використовуючи ці підходи для розширення того, що маєте, і можете адаптувати їх до своїх потреб.
Отже, це все, що я маю для вас сьогодні. Якщо ви оцінили це відео і чекаєте на більше матеріалів про ШІ-кодування та створення робочих процесів, я була б дуже вдячна за лайк та підписку. З цим, побачимося наступного разу!
Підсумовуючи: Ми розібрали, що робота з ШІ-помічниками – це не просто написання промптів, а створення цілісних систем. Ми пройшли шлях від “vibe planning” до реалізації та валідації, використовуючи такі інструменти, як слеш-команди та під-агентів. Ми побачили, як можна адаптувати ці принципи до будь-якого проєкту, створюючи власні, ефективні робочі процеси.
Заклик до дії: Не бійтеся експериментувати! Спробуйте ці підходи у своїх проєктах. Створюйте свої власні “симфонії” з коду. А щоб поглибити свої знання, не пропустіть мій майстер-клас, де ми зануримося в це ще глибше! Посилання – в описі.
У результаті, можна сказати, що ви не просто користуєтеся ШІ, ви стаєте його справжнім диригентом. Ви будуєте системи, які працюють на вас, а не навпаки. І це справжня магія сучасного кодування.
