Промптинг для нетехнічних засновників: як говорити з AI, щоб отримувати робочий код

Я не інженер за освітою. Я будую продукти — VADYM.AI, Dronehub, Oswin AI — і значну частину прототипів сьогодні збираю сам, з AI. Не тому, що раптом навчився писати код, а тому, що навчився ставити AI завдання так, щоб на виході був код, який працює.

І ось що я зрозумів за цей час: різниця між «AI пише мені сміття» і «AI пише мені робочий застосунок» — це майже завжди не модель. Це промпт. Точніше — те, наскільки чітко ви в голові уявляєте, що саме хочете отримати, і наскільки акуратно передаєте це уявлення машині.

Цей текст — практичний гайд для таких самих засновників, як я: людей з продуктовим мисленням, але без інженерного бекграунду. Без хайпу. Просто принципи й шаблони, які працюють у мене щодня.

Головна зміна в голові: ви тепер технічний директор, а не виконавець

Коли нетехнічна людина вперше сідає писати код з AI, вона робить одну й ту саму помилку — пише запит, як у Google: коротко й розпливчасто. «Зроби мені сайт-візитку.» «Напиши скрипт, що збирає дані.»

AI щось видасть. Але це «щось» майже напевно не те, що у вас у голові — бо ви й не сказали, що у вас у голові.

Правильна рамка інша. Уявіть, що ви найняли дуже швидкого, дуже начитаного, але абсолютно несамостійного джуніор-розробника. Він напише будь-що за секунди, але він не знає вашого бізнесу, не бачить картини в цілому й не здогадається про очевидне. Ваша робота — не писати код. Ваша робота — поставити йому завдання так, щоб не лишилось простору для здогадок.

Це і є головний навик. Не «знати Python». А вміти описати завдання.

Принцип 1. Завжди давайте контекст і ціль

Найслабші промпти — ті, де є дія, але немає мети. «Додай кнопку» — а навіщо? «Зроби форму» — для чого, що з нею станеться далі?

AI пише незрівнянно краще, коли розуміє навіщо. Ціль дозволяє йому добудувати деталі, про які ви не подумали.

Порівняйте:

Зроби форму реєстрації.

і

Я будую лендинг для онлайн-курсу. Мені потрібна форма реєстрації: ім'я, email, телефон. Після відправки дані мають іти на email мені й показувати користувачу повідомлення «Дякуємо, ми на зв'язку». Це для нетехнічних людей, тож форма має бути максимально проста.

У другому випадку модель знає аудиторію, призначення, поля й сценарій після відправки. Вона зробить адекватний вибір там, де ви промовчали.

Шаблон, який я використовую:

Я будую [що це за продукт]. Мені потрібно [конкретна задача]. Це для [хто користувач]. Кінцевий результат має [що має статися]. Важливо, щоб [ключове обмеження].

Принцип 2. Показуйте приклади — це найсильніший важіль

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

Замість «обробляй дату по-людськи» — покажіть:

Дати у вхідних даних виглядають як 2026-06-13. Мені треба, щоб на сайті вони показувались як 13 червня 2026. Ось ще приклади: 2026-01-01 → 1 січня 2026, 2026-12-25 → 25 грудня 2026.

Те саме працює для будь-чого: формату таблиці, структури відповіді, вигляду повідомлення. Один приклад вартий абзацу пояснень. Три приклади знімають майже всі питання.

Принцип 3. Просіть план перед кодом

Це, мабуть, найнедооціненіший прийом для нетехнічних людей. Перш ніж AI напише хоч рядок, попросіть його описати, як він збирається це робити.

Перш ніж писати код, опиши план: які файли створиш, що в кожному буде, які кроки. Я хочу спочатку погодити підхід.

Чому це критично саме для вас? Бо план написаний словами, а не кодом — і ви можете його прочитати й зрозуміти. Якщо в плані вже є щось дивне («підключу базу даних», хоча вам потрібен простий статичний сайт), ви це зловите до того, як модель напише 200 рядків у неправильному напрямку.

Сучасні AI-агенти для коду це вже вбудовують. У Claude Code від Anthropic, наприклад, є режим планування (Plan Mode): агент спершу досліджує задачу й пропонує план, і тільки після вашого підтвердження береться писати. Користуйтесь цим. Погоджений план — це договір, до якого можна повертатися: «ми ж домовились робити так».

Принцип 4. Працюйте ітераціями — малими кроками

Спокуса нетехнічного засновника — описати весь застосунок одним великим повідомленням і чекати готовий продукт. Я через це проходив. Це не працює.

Великий монолітний запит має дві проблеми. По-перше, що більше всього ви просите за раз, то більша ймовірність, що десь модель помилиться. По-друге — і це головне — коли результат не працює, ви не знаєте, де саме. Усе зламано одразу, і розбиратися ніде.

Малі кроки виглядають повільнішими, але за фактом вони швидші:

1. Спочатку — каркас сторінки. Перевірили: відкривається?
2. Тоді — форма. Перевірили: показується?
3. Тоді — відправка даних. Перевірили: лист приходить?
4. Тоді — повідомлення про успіх. Перевірили.

На кожному кроці ви маєте робочий стан, до якого можна відкотитись. Коли на кроці 3 щось ламається, ви точно знаєте: проблема у відправці, а не деінде. Це і є інженерна дисципліна, тільки без інженерної освіти.

Формулювання для ітерації:

Давай поки що тільки [один маленький шматок]. Не додавай нічого зайвого. Коли я перевірю, що це працює, перейдемо до наступного кроку.

Фраза «не додавай нічого зайвого» важлива. AI любить бути корисним і дописувати те, чого ви не просили. На етапі прототипу це шкодить.

Принцип 5. Описуйте дані й обмеження явно

Код живе серед даних. Якщо ви не сказали, які у вас дані, AI їх вигадає — і вгадає неправильно.

Завжди проговорюйте:

• Що на вході. «У мене Excel-файл, у ньому колонки: Дата, Сума, Клієнт.»
• Що на виході. «Мені треба графік продажів по місяцях.»
• Обмеження. «Файл великий, до 50 тисяч рядків.» «Це має працювати в браузері, без встановлення програм.» «Я не хочу платних сервісів.»

Обмеження — це не дрібниця, це часто головне. «Зроби без бази даних», «тільки безкоштовні інструменти», «має запускатися на моєму Mac без термінала» — кожне таке речення відсікає цілий клас рішень, які вам не підходять, і економить години.

Принцип 6. Навчіться читати помилки — і не бійтесь їх

Найбільший психологічний бар'єр для нетехнічної людини — червоний текст помилки. Виглядає страшно, незрозуміло, хочеться закрити.

Насправді помилка — це подарунок. Це найточніший контекст, який у вас є. Машина прямо каже, що пішло не так і часто навіть у якому рядку.

Правило одне: копіюйте повний текст помилки в чат, не скорочуючи й не переказуючи своїми словами.

Найгірше, що можна зробити:

Не працює, щось зламалось, поможи.

Найкраще:

Я запустив код, який ти написав, і отримав цю помилку. Ось вона повністю: [вставляєте весь traceback]. Перед цим я зробив [що саме]. Поясни простими словами, що сталося, і виправ.

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

Слабкі vs сильні промпти: таблиця

Принцип 7. Знайте, де ваша межа

Тепер важливе, про що мало хто говорить чесно. Промптинг дає вам багато — але не все. Є зона, де нетехнічному засновнику варто зупинитись і покликати інженера.

Я проводжу межу так. Усе, що стосується прототипу, внутрішнього інструменту, демо чи лендингу — збирайте самі. Ціна помилки тут — зламаний прототип, який ви просто переробите.

Але є речі, де ціна помилки інша:

• Платежі. Гроші користувачів. Тут помилка коштує грошей — буквально.
• Паролі й авторизація. Якщо зробити недбало, акаунти зламають.
• Персональні дані. Імена, email, телефони, документи людей. Це не лише етика, це закон.
• Продакшн-інфраструктура. Сервери, на яких уже працюють реальні клієнти.
• Усе, що видно публічно й масштабно.

У цих зонах AI напише код, що виглядає робочим. Він запуститься, він навіть працюватиме на ваших тестах. Але «працює на моєму прикладі» і «безпечно для тисячі реальних користувачів» — це різні речі, і різницю між ними нетехнічна людина не побачить. А інженер побачить за хвилину.

Це не слабкість. Це теж навик засновника — знати, де закінчується ваша компетенція. Я сам збираю прототипи з AI, але платежі й роботу з даними клієнтів у серйозних продуктах віддаю людям, які на цьому знаються. Прототип — мій. Продакшн із реальними грошима й даними — командний.

Як це виглядає на практиці: один сеанс

Зведу все докупи. Ось як я реально працюю, коли збираю невеликий внутрішній інструмент:

1. Контекст і ціль. Пишу абзац: що це, для кого, що має статися.
2. План. «Спершу опиши план, без коду.» Читаю, погоджую або правлю.
3. Перший крок. «Зроби тільки каркас.» Запускаю, перевіряю.
4. Помилка? Копіюю повний текст у чат. Прошу пояснити й виправити.
5. Наступний крок. Маленький. Перевіряю. І так далі.
6. Межа. Доходжу до даних користувачів — зупиняюсь, кличу інженера.

Жодної магії. Жодних секретних формулювань. Просто дисципліна: ясність на вході, перевірка на кожному кроці, чесність щодо власних меж.

Підсумок

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

Нетехнічний засновник сьогодні може зробити з AI більше, ніж будь-коли. Я це роблю щодня. Але інструмент настільки хороший, наскільки хороше завдання, яке ви йому ставите. Ясність — це і є ваш справжній навик. Усе інше машина допише сама.

І останнє: знайте, де ваша межа. Уміння сказати «тут я кличу інженера» — таке саме важливе, як уміння написати гарний промпт. Прототип збирайте самі. Реальні гроші й реальних людей довіряйте тим, хто на цьому знається.