Як зробити собі невеликий застосунок під власну щоденну задачу з допомогою ШІ, якщо ви не програміст?

Зробити невеликий застосунок під власну щоденну задачу без навичок програмування цілком реально: ви описуєте задачу словами, а модель ШІ пише програму. Найкраще для першого разу підходить одна дрібна задача, яка повторюється щодня, має зрозумілий вхід і вихід і не несе великої ціни помилки. Читати код вам не обов'язково, але перевіряти результат на вигаданих даних потрібно обов'язково. Межа такого застосунку проходить там, де з'являються чужі персональні дані, ключі доступу, платежі або публікація в інтернеті: за цією межею потрібен розробник.

Коротко

Невеликий застосунок для себе можна зробити без програмування: ви описуєте задачу словами, а модель ШІ пише код.
Для першого разу обирайте одну дрібну щоденну задачу зі зрозумілим входом і виходом та невисокою ціною помилки.
Добрий опис задачі містить, що вводиться, що має вийти, кроки роботи і приклад на вигаданих даних.
Читати код не обов'язково, але тестування на вигаданих даних і граничних випадках потрібне завжди.
Чужі персональні дані, ключі доступу, платежі й публікація в інтернеті позначають межу, за якою потрібен розробник.

Що таке застосунок для себе і чим він відрізняється від продукту для інших

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

Практику, коли людина описує потрібну програму звичайною мовою, а модель ШІ пише код, почали називати vibe coding, тобто програмуванням словами. Словник навіть визнав цей вислів словом 2025 року. Для вас головне інше: читати код не обов'язково, цю частину роботи бере на себе модель. Зате результат перевіряти доведеться вам самим, бо лише ви знаєте, яку відповідь застосунок має давати саме у вашій задачі.

Яку щоденну задачу обрати для першого застосунку

Хороша перша задача має кілька ознак. Вона повторюється щодня або щотижня. Вхід і вихід у неї зрозумілі: ви вводите кілька значень або шматок тексту і отримуєте результат. Помилка не коштує дорого, а результат легко перевірити вручну. Практика підказує ще одну перевірку: задачу варто вміти сказати одним реченням, що береться на вході і що віддається на виході.

Типових прикладів, які підходять для старту, чимало:

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

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

Як описати задачу моделі, щоб отримати робочу першу версію

Модель пише рівно те, що зрозуміла з вашого опису, тому якість першої версії залежить від того, наскільки повно ви пояснили задачу. Опишіть, що вводиться: які поля, у якому вигляді, з якими одиницями. Опишіть, що має вийти: число, текст, список чи файл. Перелічіть кроки, якими ви зараз робите цю роботу вручну. Додайте приклад вхідних даних і результату, який ви очікуєте, причому всі приклади вигадайте самі, а не беріть із реальних файлів.

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

``` Користувач не програміст. Допоможи зробити невеликий застосунок лише для одного користувача.

Задача одним реченням: [що береться на вході і що віддається на виході]. Що вводиться: [поля, формат, одиниці]. Що має вийти: [результат і його вигляд]. Кроки, якими ця робота виконується вручну: [крок], [наступний крок], [останній крок]. Приклад вигаданих даних на вході: [приклад вигаданих даних]. Очікуваний результат для цього прикладу: [очікуваний результат].

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

Спершу постав уточнювальні питання. Потім зроби найменшу робочу версію і поясни звичайними словами, як її запустити. ```

Як отримати й запустити першу версію

Загальних шляхів два. Перший: конструктор застосунків за описом, який працює в браузері: ви вставляєте опис, і він зазвичай швидко показує готову сторінку, яку можна спробувати. Другий: чат-асистент, який пише одну сторінку або невелику програму і пояснює, як відкрити її на вашому комп'ютері. Обидва шляхи придатні для першого разу, а вибір залежить від того, що вам зручніше і що дозволяють правила вашої компанії.

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

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

Як перевірити застосунок на вигаданих даних, якщо ви не вмієте читати код

Тестування починається з набору вигаданих даних, для яких ви заздалегідь знаєте правильну відповідь. Порівняйте результат застосунку з ручним підрахунком на кожному прикладі. Додайте граничні випадки, тобто ситуації на краях звичайного: порожнє поле, дуже велике число, незвичний формат дати, текст кирилицею, зайві пробіли на початку чи в кінці. Саме на них програми нерідко помиляються. Кожну зміну перевіряйте ще раз на тих самих тестових даних.

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

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

Де зупинитися: реальні персональні дані, ключі доступу і платежі

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

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

Третя межа стосується платежів. Застосунок для себе не приймає й не зберігає дані платіжних карток і не керує чужими грошима. Галузевий стандарт безпеки платіжних карток для малого бізнесу виходить з того, що найкращий захист від витоку полягає в тому, щоб дані карток не зберігати взагалі, а обробку віддати сертифікованому провайдеру. Коли платежі справді потрібні, вони проходять через готову платіжну сторінку провайдера: дані картки вводяться на його боці, а ваша програма отримує лише знеособлений токен замість номера. Дані картки також не радять приймати електронною поштою.

Окремо про публікацію. Щойно застосунок треба викласти в інтернет або дати ним користуватися всій команді, він перестає бути застосунком для себе. Захист від сторонніх, розподіл доступів і стабільна робота для багатьох людей вже належать до завдань розробника.

Як підтримувати застосунок і коли звернутися до розробника

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

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

Що робити далі

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