Підтримка застосунків, зібраних зі ШІ: чого ніхто не каже про другий тиждень

Першими вихідними з Proyecta ви випускаєте щось справжнє. Воно працює. Ваші користувачі (чи ваша команда, чи ваше майбутнє «я») починають ним користуватися. А потім настає понеділок, і клієнт пише: «Можете додати випадне меню, щоб фільтрувати за регіоном?»

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

Що насправді означає підтримка

Коли професійні розробники кажуть «підтримка», вони мають на увазі чотири речі, більш-менш:

1. Додавання маленьких функцій, які люди просять після запуску.
2. Виправлення речей, що зламалися чи були хибними від початку.
3. Встигання за змінами поза вашим застосунком — платіжний провайдер оновлює свій API, виходить новий браузер, змінюється форма ваших даних.
4. Прибирання, щоб кодова база повільно не перетворилася на болото.

Для застосунку на ШІ всі чотири все одно трапляються. Що змінюється — це хто їх робить і як ця робота відчувається.

Хороша новина: ви можете з ним говорити

Ось частина, про яку вам ніхто не казав, коли ви копіювали-вставляли код зі старих туторіалів. З конструктором застосунків на ШІ ви підтримуєте застосунок так само, як його збудували: описуючи те, що хочете.

Реальний приклад. Знайома нам засновниця зібрала невелику CRM для своєї коучингової практики — клієнти, сесії, відстеження платежів, усе. За три тижні після запуску клієнтка згадала, що хотіла б бачити, скільки сесій вона провела того року. Засновниця відкрила застосунок і сказала: «Додай лічильник “сесій цього року” до кожної картки клієнта, підтягуючи з таблиці сесій, де дата у 2026 році». За дванадцять хвилин це було наживо. Вона повернулася до коучингу.

Ця історія звучить нормально, доки ви не згадаєте альтернативу: написати фрилансеру, чекати два дні, заплатити $300, переглянути PR, який вона не до кінця розуміла, і молитися, щоб більше нічого не зламалося. Цикл підтримки швидший не тому, що ШІ розумніший за фрилансера. Він швидший, бо в циклі менше людей.

Складніша новина: маленькі речі накопичуються

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

Кілька патернів, які ми бачимо, що йдуть не так:

• Випадковий клубок. Ви просите «додай поле знижки до оформлення замовлення». Шість правок потому логіка знижки живе у трьох місцях, і лише одне з них правильне. Поки нічого не зламалося, але наступна зміна буде заплутаною.
• Забута вимога. Ви додали «безкоштовна доставка від $50» у березні. У травні ви просите ШІ «переробити оформлення замовлення, щоб підтримувати подарункові картки». Він це робить. Правило безкоштовної доставки зникло. Ніхто не помічав два тижні.
• Дрейф. Ваш застосунок почався як «інструмент для мене». Тепер ним користується ваша команда. Ментальна модель, з якої виходить ШІ, усе ще «для мене», бо саме це ви спочатку сказали. Нові функції відчуваються дивно невідповідними, і ви не можете зрозуміти чому.

Жодне з цього не провал конструкторів застосунків на ШІ. Це провали пам’яті й спільного контексту — ті самі проблеми, що має команда людей-розробників, просто в іншій формі.

Як налаштуватися

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

Ведіть документ «чим є цей застосунок». Одна сторінка. Аудиторія, цілі, правила («безкоштовна доставка від $50», «ми ніколи не пишемо користувачам у неділю», «телефон — первинний ключ, а не e-mail»). Коли ви просите ШІ щось змінити, вставте відповідне правило у промпт. Ви не обходите інтелект ШІ; ви годуєте його контекстом, який він ніяк не може пам’ятати.

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

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

Дивіться, що змінилося. Більшість конструкторів застосунків на ШІ показують вам попередній перегляд. Користуйтеся ним. Тридцять секунд, які ви витрачаєте, клікаючи навколо, щоб підтвердити, що нова функція працює і старі функції все ще працюють, — найдешевша страховка, яку ви купите цього року.

Чого ви не можете зробити (і, ймовірно, не варто)

Є спокуса, щойно ви зібрали застосунок зі ШІ, думати, що він також може ним керувати за вас. Він не може, і розрив реальний:

• Він не скаже вам, коли щось тихо зламалося. Логи, моніторинг, чергування на дзвінку — це все ще окрема справа. Більшість конструкторів застосунків на ШІ не спостерігають за вашим продакшен-застосунком так, як це робив би бекенд-інженер.
• Він не знає про світ поза вашим застосунком. Якщо платіжний провайдер виводить API з ужитку, ШІ не знає, доки ви йому не скажете. Підпишіться на чейнджлоги своїх провайдерів. Читайте свою пошту.
• Він не може ухвалювати продуктові рішення за вас. Чи додавати функцію, який компроміс зробити, чого ваші користувачі справді хочуть — це все ще ви. ШІ — дуже швидкі руки; мозок ваш.

Реалістична картина

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

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

Якщо ви збираєтеся зібрати свій перший застосунок, допис про те, яким має бути ваш перший застосунок на ШІ варто прочитати перед стартом. А якщо ви вже кілька тижнів у справі й відчуваєте деякі з патернів вище, це нормально. Напишіть свій документ «чим є цей застосунок» цими вихідними. Майбутнє «ви», за три місяці, що проситиме новий дашборд, буде дуже радим, що ви це зробили.