Еволюція мого кодингу: від ChatGPT у браузері до OpenClaw у хмарі GCP

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

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

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

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

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

Чому проблема була не тільки в коді, а в самому процесі

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

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

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

Етап 1. Копіпаст у браузері: ChatGPT + зовнішній редактор

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

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

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

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

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

Етап 2. Інтеграція AI прямо у VS Code

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

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

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

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

Тобто AI уже був поруч, але сам процес усе ще був розбитий на купу дрібних ручних дій. І саме ці дрібні дії в сумі з’їдають дуже багато енергії.

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

Тобто це був уже крок уперед, але ще не той режим, у якому можна будувати справжній конвеєр.

Етап 3. Перехід на OpenClaw: від підказок до реального виконавця

Справжній перелом стався тоді, коли я відкрив для себе OpenClaw. І саме тут для мене почалося не просто “AI у розробці”, а вже нормальна робоча модель, де агент стає частиною середовища, а не просто вікном із відповідями.

Різниця дуже проста. До цього AI був переважно підказчиком. Він міг допомогти, пояснити, дописати, але дуже часто залишав усю реальну роботу на мені. З OpenClaw підхід став іншим: агенту можна одразу дати набагато більше прав і підключити його не тільки до коду, а й до всього ланцюжка навколо.

Тобто він уже працює не “десь збоку”, а одразу в зв’язці з середовищем розробки, GitHub, консоллю, сервером, хостингом, а за потреби навіть із доменами й тестовим оточенням. Це означає, що по команді він може не просто написати шматок коду, а виконати реальну задачу від початку до кінця: підняти сайт, щось перевірити, зробити базовий тест, внести правки, оновити проєкт, підготувати зміни до деплою.

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

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

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

Етап 4. Хмара, безпека і правило нульових витрат

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

Мені потрібно було середовище, яке доступне 24/7, яке можна відкрити з будь-якого пристрою, де стабільно крутяться агенти, робочі процеси, інструменти, бази, перевірки і вся технічна кухня. Хотілося, щоб “студія розробки” перестала бути прив’язаною до одного ноутбука або конкретного робочого місця.

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

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

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

Я справді спочатку думав просто взяти окрему машину під цю роботу. Це був найочевидніший варіант: виділити окремий комп’ютер або сервер, не змішувати все з особистим середовищем і зібрати там свою студію розробки. Але вчасно побачив можливість скористатися кредитами від Google Cloud Platform і пішов у цей бік. Саме це дозволило не вкладатися в окрему залізяку на старті й одразу зібрати середовище в хмарі. Детальніше про цю можливість я писав тут: пропозиція від Google Cloud.

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

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

Що зараз крутиться в моїй віртуалці

Зараз у мене на віртуальній машині живе вже не просто “агент для коду”. Це фактично окрема міні-студія розробки й автоматизації.

У цьому середовищі в мене працюють сам агент, n8n, середовище розробки, git, вебсервер і обробник голосу. І головна сила тут у тому, що все це не існує окремо, а працює в зв’язці.

Агент за допомогою n8n та різних інтеграцій не тільки пише код, деплоїть, робить коміти в git і піднімає домени для тестування. Він також витягує дизайни з Figma, пише та розкладає документацію, створює і змінює задачі та проєкти в CRM, приймає і публікує контент. Тобто це вже не “інструмент для програміста”, а універсальний технічний виконавець, який працює на стику розробки, автоматизації, контенту й операційки.

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

Від хаосу до конвеєра

Якщо коротко описати головну зміну, то вона не в тому, що я знайшов “магічний AI-інструмент”. Головна зміна в тому, що я перестав дивитися на розробку як на серію випадкових ручних дій і почав будувати її як систему.

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

Саме тому сьогодні я вже думаю не категорією “чи можу я зібрати один застосунок”, а категорією “як побудувати конвеєр, у якому десятки продуктів проходять через однакову, керовану й досить дешеву систему”.

Що насправді змінилося в моїй ролі

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

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

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

Що це змінило в моєму підході до продуктів

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

Саме тому сьогодні я дивлюся на розробку не як на “навчання писати код”, а як на побудову системи виробництва цифрових продуктів. Десь це мобільні застосунки, десь SaaS, десь внутрішні інструменти, десь контентні й автоматизаційні зв’язки. Але логіка одна: менше ручної механіки, менше хаосу, більше повторюваності.

І це дуже сильно змінює швидкість. Не обов’язково в сенсі “один конкретний екран написався за 10 хвилин”. А в сенсі, що весь шлях від ідеї до тестового продукту стає коротшим, чистішим і менш виснажливим.

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

Хочете, щоб я вам так само налаштував? Давайте обговоримо.

Чому цей підхід мені підходить саме зараз

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

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

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

Висновок

Мій шлях від ChatGPT у браузері до OpenClaw у хмарі — це не історія про те, як я “раптом став програмістом”. Це історія про те, як я поступово збирав для себе спосіб створювати продукти в умовах обмеженого часу, обмеженого ресурсу і майже нульового стартового досвіду саме в мобільній розробці.

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

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

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