# Спеки замість коду: покрокова інструкція для AI-білдера-початківця > Як писати структуровані специфікації, щоб Cursor, Claude або Codex генерував реальний код — а не іграшкові приклади. - Опубліковано: 18 червня 2026 р. (2026-06-18T04:51:32.443157+00:00) - Розділ: vibecoding - Видання: AiiN (https://aiin.news) - URL: https://aiin.news/article?slug=%D1%81%D0%BF%D0%B5%D0%BA%D0%B8-%D0%B7%D0%B0%D0%BC%D1%96%D1%81%D1%82%D1%8C-%D0%BA%D0%BE%D0%B4%D1%83-%D0%BF%D0%BE%D0%BA%D1%80%D0%BE%D0%BA%D0%BE%D0%B2%D0%B0-%D1%96%D0%BD%D1%81%D1%82%D1%80%D1%83%D0%BA%D1%86%D1%96%D1%8F-%D0%B4%D0%BB%D1%8F-ai-%D0%B1%D1%96%D0%BB%D0%B4%D0%B5%D1%80%D0%B0-%D0%BF%D0%BE%D1%87%D0%B0%D1%82%D0%BA%D1%96%D0%B2%D1%86%D1%8F --- Ще рік тому питання «як писати код» мало на увазі IDE, синтаксис і налагоджувач. Сьогодні для значної частини AI-білдерів воно означає зовсім інше: як точно описати задачу, щоб Cursor, Claude або Codex написав код замість тебе. Змінилася не задача — змінився виконавець. Цей підхід має назву spec-driven vibe coding: замість рядків коду ви пишете специфікацію — структурований опис того, що має робити програма. Модель перетворює опис на реальний код. Але тут є нюанс, який новачки часто ігнорують: якість коду прямо залежить від якості спеки. Сміття на вході — сміття на виході, і жодний GPT-5 це не врятує. Стаття — для тих, хто хоче будувати продукти з допомогою AI, але ще не звик думати специфікаціями. Жодних передумов: достатньо вміти формулювати думки по-українськи або по-англійськи. ## Що таке спека і чим вона відрізняється від «промпта» Промпт — це одноразовий запит. Спека — це документ (або структурований текст), який описує систему цілком: що вона робить, для кого, які правила, які обмеження, які інтерфейси. Різниця критична. Промпт «зроби мені телеграм-бота» дасть вам Hello World за 30 секунд і нічого більше. Спека того самого бота виглядає так: - **Контекст**: бот для малого бізнесу, приймає замовлення через /order - **Дії**: зберігає ім'я, телефон, коментар у Supabase - **Стан**: підтверджує замовлення, надсилає адміну повідомлення у форматі Markdown - **Обмеження**: без inline-кнопок, тільки текстові команди - **Стек**: Python, python-telegram-bot 20.x, Supabase Python client Ця спека займає 10 рядків, але дає Claude або Codex достатньо контексту для генерації реального, а не іграшкового коду. ## Покроковий процес: від ідеї до робочого коду **Крок 1. Сформулюйте ціль одним реченням.** «Я хочу X, щоб Y міг робити Z.» Наприклад: «Я хочу веб-форму, щоб клієнт міг залишити заявку і отримати підтвердження на email.» Якщо не можете вкласти ціль в одне речення — задача ще не визначена. **Крок 2. Визначте користувача і сценарій.** Хто взаємодіє з системою? Що вони роблять крок за кроком? Запишіть як список: заходить → бачить форму → вводить дані → натискає «Надіслати» → отримує сповіщення. Цей список стає кістяком спеки. **Крок 3. Вкажіть стек.** AI-моделі не телепати. Якщо ви не скажете, вони вибиратимуть стек самі — і не завжди вдало. Напишіть прямо: Next.js + Resend для email, або FastAPI + SQLite, або чистий HTML без фреймворків. Це найефективніший спосіб уникнути «сюрпризів» у вигляді застарілих бібліотек. **Крок 4. Опишіть обмеження.** Чого _не_ повинен робити код? Без авторизації? Без бази даних? Лише один файл? Без зовнішніх залежностей? Обмеження — це не слабкість спеки, це її сила. Вони звужують простір рішень і зменшують кількість ітерацій. **Крок 5. Вкажіть формат виводу.** Ви хочете один файл? Кілька файлів з поясненням? Тільки функцію без обв'язки? Інструкцію з запуску? Чим конкретніше — тим менше зайвих уточнень від моделі. **Крок 6. Ітеруйте по частинах.** Не намагайтеся написати спеку всього продукту одразу. Розбийте на модулі: спочатку авторизація, потім форма, потім email. Кожен модуль — окрема спека, окрема генерація. Так легше перевіряти і виправляти помилки до того, як вони накопичаться. ## Типові помилки початківців зі спеками **Занадто загально.** «Зроби мені сайт» — це не спека. Немає стеку, немає аудиторії, немає структури. Результат буде відповідним. **Змішування шарів.** Спека намагається одночасно описати UI, бізнес-логіку, базу даних і деплой. Модель губиться. Пишіть окремі спеки для кожного шару. **Ігнорування обмежень.** Без явних обмежень Codex або v0 додадуть те, що вважають «best practice» — часто це зайве для вашого випадку. Явно кажіть «без TypeScript», «без тестів», «без Docker», якщо вони вам не потрібні. **Відсутність контексту стану.** Якщо ви доопрацьовуєте існуючий код, покажіть моделі поточний стан: вставте фрагмент коду або структуру файлів. Без цього вона пише «з нуля» і ламає те, що вже є. **Очікування ідеального результату з першого разу.** Спека — це перший прохід. Очікуйте 70–80% готовності з першої генерації. Уточнення і доопрацювання — норма процесу, не його провал. ## Висновок AiiN Spec-driven підхід — це не магія і не обхід навчання. Це новий тип грамотності: вміння описувати системи точно і структуровано. Ця навичка корисна незалежно від того, пишете ви код самі чи делегуєте його Cursor, Replit або Bolt. Почніть з малого: візьміть будь-яку задачу, яку ви б вирішили вручну, і напишіть для неї спеку за шістьма кроками вище. Перевірте результат. Уточніть. Запустіть знову. Після п'яти-десяти ітерацій ви відчуєте різницю між «промптом навмання» і «спекою з наміром». AI-моделі стають кращими щомісяця. Але спека, написана чітко сьогодні, дасть кращий код навіть на середній моделі, ніж розмита ідея на найновішій. Контроль залишається за вами. --- Теги: vibecoding, AIdev, специфікація, Cursor, prompting, AIбілдер Джерело: AiiN — https://aiin.news/article?slug=%D1%81%D0%BF%D0%B5%D0%BA%D0%B8-%D0%B7%D0%B0%D0%BC%D1%96%D1%81%D1%82%D1%8C-%D0%BA%D0%BE%D0%B4%D1%83-%D0%BF%D0%BE%D0%BA%D1%80%D0%BE%D0%BA%D0%BE%D0%B2%D0%B0-%D1%96%D0%BD%D1%81%D1%82%D1%80%D1%83%D0%BA%D1%86%D1%96%D1%8F-%D0%B4%D0%BB%D1%8F-ai-%D0%B1%D1%96%D0%BB%D0%B4%D0%B5%D1%80%D0%B0-%D0%BF%D0%BE%D1%87%D0%B0%D1%82%D0%BA%D1%96%D0%B2%D1%86%D1%8F. Цитуючи, посилайтесь на канонічний URL.