https://blog-archive.alexkolodko.com/tags/ai/ Олександр Колодько. Інформаційний та навігаційний дизайнер. Співзасновник команди ARC, співзасновник та головний дизайнер в Агентах змін (А3). Пишу про дизайн і цікаве мені · alexkolodko.com · wayfinding.systems uk Aegea 11.3 (v4134) Олександр Колодько. Інформаційний та навігаційний дизайнер. Співзасновник команди ARC, співзасновник та головний дизайнер в Агентах змін (А3). Пишу про дизайн і цікаве мені · alexkolodko.com · wayfinding.systems 164 https://blog-archive.alexkolodko.com/all/cursor-and-novibecoding/ Sun, 11 Jan 2026 18:53:45 +0200 https://blog-archive.alexkolodko.com/all/cursor-and-novibecoding/ <p>Понад рік використовую Cursor для створення робочих інструменті: від окремих скриптів до робочих застосунків та плагінів для браузера. Влітку мені навіть писали з Курсору, сказали що я у «топ 1% юзерів в Києві» (хз, як вони це міряли) та запрошували на мітап 😁</p> <p>І зараз вони зробили підсумки року, у вигляді красивої сторінки та красивих цифр — 3,4 тисяч агентів (чатів) та 1,69 млрд токенів. На початку найбільше використовував модель Claude, у порівнянні з іншими вона давала завжди більш робочий результат. Потім авторежим моделі, і коли він не давав потрібний результат перемикав вручну на Claude. Останнім часом пробую їхню модель Composer, яка менша і працює швидше.</p> <div class="e2-text-picture"> <img src="https://blog-archive.alexkolodko.com/pictures/cursor-2025-models.png" width="1728" height="1000" alt="" /> </div> <div class="e2-text-picture"> <img src="https://blog-archive.alexkolodko.com/pictures/cursor-2025.png" width="1080" height="1080" alt="" /> </div> <p>Що цікавого можу відмітити за рік використання.</p> <p><b>Самотужки можна закривати фулстек — повністю створювати застосунки </b><br /> Вдається за відсутності додаткових спеціалістів з технологій, які ви не так знаєте (для мене це бекенд), створювати працюючі застосунки, які вирішують задачу. У нагоді, стають знання як раз з проєктування і дизайну, які дозволяють придумати і описати бажаний результат, протестувати його і переробити за потреби.</p> <p><b>Використання будь-яких мов програмування</b><br /> Є частина інструментів які створені для Python, деякі — як вебфреймворк, або ж щось під бази даних. Раніше на їх вивчення могло б піти багато часу, щоб зрозуміти, як правильно працювати з тою чи іншою мовою та технологією. Особливо це стосується веб-фреймворків, які, таке відчуття, що кожен пише свій, і тільки на те, щоб його обрати треба витратити додаткові когнітивні зусилля (а може я вже старий, бо чистий JS мені зрозуміліший). Я так збирав по частинах одну апку, де частину роботи виконують Python-скрипти, як-то транскрибація аудіо в текст за допомогою Whisper, а вже фронт зроблений на NextJS.</p> <p><b>LLM допомагають перекласти звичайну мову у мову програм</b><br /> Є багато вже розроблених програм, часто які працюють в консолі/терміналі, і які насправді можуть закривати багато поточних потреб і рутинних задач. Але у них високий поріг входу: треба розуміти як це працює і як їх використати. Так от LLM, на мій погляд, прекрасно підходять для того, щоб почати їх використовувати у повсякденній роботі. Наприклад, я зробив пачку швидких дій у MacOS які конвертують картинки чи відео в різні формати, або ж роблять відео на швидкості ×2…×4, коли я роблю скрінкаст і демо роботи чогось, роблять чи розбирають PDF, зклеює картинки тощо (якщо цікаво, окремо покажу та розпишу приклади). Зокрема по цій схемі існує цілий застосунок AI-термінал — Warp. Так і Cursor активно взаємодіє з термінальними програмами.</p> <p><b>Ідеально для R&D та малих проєктів</b><br /> Цей пункт випливає з попередніх. Це можливість швидко зібрати робочий прототип і протестувати чи все працює як задумано. І далі або розвивати далі створений інструмент чи викинути й попробувати щось робити інакше. Іноді навіть створити дашборд з візуалізацією ваших даних іноді навіть простіше і швидше згенерувавши сторінку на D3.js, ніж намагаючись зробити те саме в Екселі. Але важливо розуміти, що інструменти генерації коду, можливо, не роблять ідеальний код і тому його треба використовувати обережно у великих проєктах та проєктах, де важлива безпека.</p> <p><b>Простіше починати одразу з коду, а не з макета у Figma</b><br /> Помітив за собою що вже не так хочеться робити макети у Фігмі, які потім потрібно якось ще переносити у код, і набагато простіше одразу почати роботу з кодом, отримуючи вже інтерактивний інструмент, замість придумування і малювання окремих версій усіх елементів. Так AI/LLM може понапридумувати аж занадто своєрідний стиль, особливо якщо не сильно описати бажаний результат, але за кілька ітерацій результат вдається стабілізувати. Тут у нагоді може стати подивитись як запит обробляє Firebase: детально описує стиль тексту та іконок, кольори, анімацію.</p> <div class="e2-text-picture"> <img src="https://blog-archive.alexkolodko.com/pictures/firebase-prompt-example@2x.png" width="830" height="854" alt="" /> <div class="e2-text-caption">Результат обмірковування моделі перед створенням самого коду застосунку</div> </div> <p><b>Залежність від інструментів</b><br /> Але є і суттєвий мінус: коли щось трапляється з оплатою, або немає можливості підключитись для використання моделей — вважайте що лишаєтесь безпорадними, не в змозі продовжувати активну роботу. На відміну від знання мови, яке можна використати не залежно від наявності підписки. Сюди ж можна додати використання будь-яких мов у різних проєктах — поступово просто перестаєш пам’ятати як влаштовані різні проєкти і через це більше потребуєш моделей, які мають то все зчитувати.</p> <h2>Особливості роботи з генерацією коду</h2> <p><b>Написання документації та інструкцій</b><br /> Щоб Курсор чи інші моделі згенерували вам найбільш точний результат — йому потрібно якомога точніше описати, що вам треба. Тобто як і в класичному процесі розробки — створити документацію. І цей крок має бути першим. Це іноді трохи лінь робити, бо доводиться описувати наче очевидні речі. В принципі, для цього у тому ж Курсорі присутній режим Планування — на ваш запит і опис модель створює план (як звичайний ntrcnjdbq md-файл) з описом кроків. Що дає змогу почати. Або ж іти меншими кроками нарощуючи потрібні функції і потрібний вигляд саме почерговими запитами.</p> <p><b>Знання бази та перевірка результату</b><br /> Як і результат будь-яких мовних моделей результати створення коду треба перевіряти на галюцинації. І бажано орієнтуватись хоча б базово це цикл, де умови, де змінні та функції тощо. Ну і просити модель просто поміняти колір елементу через запит — це не ефективне використання ресурсів.</p> <h2>Що почитати</h2> <p>Українською не так багато матеріалів на тему, але оці цікаві:</p> <ul> <li><a href="https://dou.ua/forums/topic/57057/">Технічна база для дизайну — те, про що соромно запитати у розробників</a>. Для дизайнерів без досвіду розробки у цій статті від роз’яснення основ, до початку використання цього у роботі разом</li> <li><a href="https://dou.ua/forums/topic/56845/">Cursor Rules: як навчити AI працювати з вашим проєктом</a>. Поради по тоншому налаштуванню Cursor: використання правил .cursorrules, AGENTS.md тощо.</li> </ul> <h2>Душний p.s.</h2> <p>І трохи душноти під кінець стосовно самого терміну «вайбкодінг», який придумав Андрей Карпати. Процес спілкування і використання моделей взагалі не імітує вайб настрій програмування, коли в голові проєктуєш і потім руками відтворюєш алгоритм роботи програми, і відчуття задоволення, коли програма виконує само те, що треба. Окреме задоволення в процесі можна отримувати від вигадування красивішого простішого коротшого алгоритму в коді, який ніхто окрім розробників і не побачить.</p> <p>Процес проєктування більш схожий на сцену з Залізної людини, коли Тоні Старк проєктує в голові загальну концепцію і розуміє, що конкретно треба, але всю реалізацію бере на себе Джарвіс. Так і з Курсором: проєктуючи у себе в голові, цеглинка за цеглинкою складається і розвивається готове рішення.</p>