Коли конструктор застосунків на ШІ губить нитку: повертаємо збірку на рейки, не починаючи спочатку

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

Не варто. Конструктор застосунків на ШІ не зламався; він загубив нитку. Це дуже виправний стан, і вам не треба знищувати проєкт, щоб із нього вибратися.

Що насправді означає «загубити нитку»

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

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

Ви зазвичай помітите це через одну з трьох ознак.

Ознака 1: ШІ переписує те саме

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

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

Коли це стається, трюк — заякорити його. Перестаньте описувати зміну в абстрактних термінах («зроби кнопку входу чистішою») і почніть описувати її в термінах, які ШІ може зіставити з тим, що насправді на екрані («кнопка наразі каже “Увійти”, відцентрована й синя — збережи всі три, просто зроби кути округлими»). Ви даєте ШІ свіжий знімок. Те, що стабільно допомагає нерозробникам вийти з цього циклу, — речення, що каже «наразі воно робить X — зміни лише Y».

Ознака 2: кожне виправлення ламає щось інше

Ви повідомляєте про зламану форму реєстрації. ШІ виправляє форму. Ви перезавантажуєте сторінку, і макет дашборда зсунувся. Ви просите повернути дашборд назад. Форма реєстрації ламається знову.

Це спіраль, що лякає людей до того, щоб починати спочатку, і це найпоширеніша причина, чому збірки покидають на 80% готовності. Що відбувається під сподом — це що ШІ торкається файлів чи компонентів, що впливають на більше, ніж область, про яку ви просили. Засновник, якого я нещодавно спостерігав, попросив ШІ «виправити кольори на головній сторінці» й опинився з іншою навігаційною панеллю усюди — бо стилі, що живлять обидва, жили в тому самому місці, і ШІ виправив обидва одразу. Він думає, що виправляє одну річ; насправді він редагує дві.

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

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

Ознака 3: ШІ ставить вам ті самі запитання

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

Це зазвичай означає, що ШІ загубив контекст рівня проєкту. Він працює з останніми кількома повідомленнями, а не з архітектурними рішеннями, які ви ухвалили раніше. Ви не можете його по-справжньому винуватити; люди роблять те саме на довгих нарадах. Але результат у тому, що ви постійно перерозглядатимете фундамент, поки намагаєтеся будувати другий поверх.

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

Маленький плейбук, щоб зрушити з місця

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

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

Назвіть мету одним реченням. Уголос, на письмі, десь. «Я намагаюся зробити так, щоб форма реєстрації приймала e-mail і пароль і надсилала вітальне повідомлення». Якщо ви не можете назвати це одним реченням, це частина того, чому ШІ дрейфує — він віддзеркалює вашу власну двозначність назад.

Ізолюйте зламаний шматок. Скажіть ШІ, якої сторінки, компонента чи функції йому дозволено торкатися. Будьте конкретні. «Редагуй лише форму реєстрації. Нічого іншого не міняй». Якщо ви не можете точно назвати, що зламано, попросіть ШІ підсумувати, що він останнім змінив; це часто виявляє справжній рухомий шматок.

Заякоріть зміну до того, що там зараз. Опишіть поточний стан і цільовий стан. «Наразі воно показує червоне повідомлення про помилку під полем пароля. Я хочу, щоб це повідомлення зникало, коли користувач починає набирати знову». Конкретне до-і-після б’є абстрактний намір.

Візьміть перемогу й зупиніться. Найважча частина всього списку. Коли збірка повернулася в робочий стан, збережіть і відійдіть на кілька хвилин. Не намагайтеся одразу виправити наступну річ. Збірки, що множать чотири-п’ять виправлень поспіль, схильні входити в чергову спіраль. Збірки, що виправляють одну річ, зберігають і роблять паузу, — ні.

Коли справді час починати спочатку

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

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

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