Як удосконалювати застосунок, створений з AI, і не зламати його

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

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

Цикл удосконалення

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

Кожен крок існує, щоб зміни залишалися малими і оборотними.

Крок 1: Складіть короткий список

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

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

Крок 2: Описуйте, що бачите

AI не бачить вашого екрана, якщо ви йому не скажете. Вказуйте на конкретні речі і пояснюйте, що має статися:

На сторінці цін на телефоні кнопка картки Pro обрізана з правого краю. Залиште десктопний вигляд без змін; на екранах менше 640 px складіть картки в стовпчик і зробіть кнопки на всю ширину.

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

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

Крок 3: Плануйте перед великими змінами

Для всього, що зачіпає кілька частин застосунку — нова модель даних, платежі, ролі користувачів, — попросіть план до будь-яких змін у коді:

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

Прочитайте план. Якщо він неправильний, виправити план набагато дешевше, ніж відкочувати побудову.

Крок 4: Скажіть, що не можна змінювати

Інструменти для AI іноді «прибирають» те, про що ви не просили. Захистіть те, що працює:

Додай фільтр за датою в таблицю замовлень. Не змінюй колонки таблиці, стилі чи кнопку експорту.

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

Крок 5: Перевіряйте більше, ніж зміну

Після кожного промпту перевіряйте:

• Саму зміну. Чи робить вона те, що ви просили, на десктопі і на телефоні?
• Сусідні частини. Речі на тій самій сторінці і потоки, які використовують ті самі дані.
• Критичний шлях. Реєстрація, вхід, головна дія, оплата. Тридцятисекундна перевірка після великих змін виявляє більшість поломок на ранньому етапі.

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

Крок 6: Відкочуйтеся, а не нашаровуйте

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

Замість цього:

1. Відкотіться до останньої робочої версії (контрольної точки або коміту в Git).
2. З'ясуйте, що було неясним у промпті.
3. Спробуйте знову з меншим або чіткішим запитом.

Ця зміна зламала збереження чернеток. Я відкотив. Цього разу: додай лише індикатор автозбереження як текст у заголовку. Не змінюй те, як зберігаються чернетки.

Крок 7: Знайте, коли перебудова доречна

Перебудова з нуля відкидає багато робочих деталей. Вона виправдана лише коли:

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

Якщо перебудовуєте, складіть список того, що зберегти: назву, кольори, текст, частини, які сподобалися користувачам.

Приклади промптів

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

Я хочу додати повторювані бронювання. Яка найменша версія буде корисною? Запропонуй її як три окремі зміни, які ми зробимо по одній.

Перегляньте останні три зміни на предмет того, що могло зламати потік оплати. Поки не редагуйте.

Типові помилки

• Десять запитів в одному промпті. Частину зроблять, частину — наполовину, і ви не зрозумієте, яку саме.
• Розпливчастий відгук. «Не працює» або «зроби краще» породжує здогадки.
• Ніколи не перевіряти сусідів. Зміна спільного компонента ламає ще три сторінки.
• Виправляти виправлення. Якщо ви на четвертому промпті щодо однієї помилки — відкотіться.
• Повторювати контекст щоразу замість того, щоб тримати сталі правила в нотатках проєкту.
• Перебудовувати, коли застрягли. Більшість моментів «почнемо спочатку» насправді означають «відкотіться на два кроки».

Чек-лист

• Одна мета на промпт.
• Я описую, що бачу, і що має статися.
• Великі зміни отримують план до будь-якого коду.
• Я кажу, що не можна змінювати.
• Після кожної зміни я перевіряю її, сусідні частини і критичний шлях.
• Я зберігаю контрольну точку або коміт після кожної робочої зміни.
• Коли виправлення не спрацьовує, я відкочуюся, а не нашаровую.
• Сталі правила живуть у нотатках проєкту, які AI читає щоразу.

Удосконалення в Mythex

Mythex побудовано навколо цього циклу:

• Режими Plan, Build і Ask. Plan обговорює підхід до редагування; Ask відповідає, не змінюючи код; Build вносить зміну. Див. Чат.
• Контрольні точки. Після кожного успішного ходу Mythex зберігає git-контрольну точку; Revert to this point відкочує назад. Ви також можете відредагувати попереднє повідомлення і натиснути Discard & resend, щоб спробувати інший промпт з тієї точки. Див. Удосконалення без перебудови.
• Знання. Налаштування проєкту → Knowledge містить сталі нотатки, яких агент дотримується в кожному повідомленні.
• /test змушує агента пройтися по превʼю, як користувач, після великої зміни.

Коротші запити також коштують менше кредитів. Про написання самих промптів — як писати промпти для AI-білдерів; коли щось таки зламалося, — як налагодити застосунок, створений з AI.

Запитання