Понад рік використовую Cursor для створення робочих інструменті: від окремих скриптів до робочих застосунків та плагінів для браузера. Влітку мені навіть писали з Курсору, сказали що я у «топ 1% юзерів в Києві» (хз, як вони це міряли) та запрошували на мітап 😁

І зараз вони зробили підсумки року, у вигляді красивої сторінки та красивих цифр — 3,4 тисяч агентів (чатів) та 1,69 млрд токенів. На початку найбільше використовував модель Claude, у порівнянні з іншими вона давала завжди більш робочий результат. Потім авторежим моделі, і коли він не давав потрібний результат перемикав вручну на Claude. Останнім часом пробую їхню модель Composer, яка менша і працює швидше.

Що цікавого можу відмітити за рік використання.

**Самотужки можна закривати фулстек — повністю створювати застосунки ** Вдається за відсутності додаткових спеціалістів з технологій, які ви не так знаєте (для мене це бекенд), створювати працюючі застосунки, які вирішують задачу. У нагоді, стають знання як раз з проєктування і дизайну, які дозволяють придумати і описати бажаний результат, протестувати його і переробити за потреби.

Використання будь-яких мов програмування Є частина інструментів які створені для Python, деякі — як вебфреймворк, або ж щось під бази даних. Раніше на їх вивчення могло б піти багато часу, щоб зрозуміти, як правильно працювати з тою чи іншою мовою та технологією. Особливо це стосується веб-фреймворків, які, таке відчуття, що кожен пише свій, і тільки на те, щоб його обрати треба витратити додаткові когнітивні зусилля (а може я вже старий, бо чистий JS мені зрозуміліший). Я так збирав по частинах одну апку, де частину роботи виконують Python-скрипти, як-то транскрибація аудіо в текст за допомогою Whisper, а вже фронт зроблений на NextJS.

LLM допомагають перекласти звичайну мову у мову програм Є багато вже розроблених програм, часто які працюють в консолі/терміналі, і які насправді можуть закривати багато поточних потреб і рутинних задач. Але у них високий поріг входу: треба розуміти як це працює і як їх використати. Так от LLM, на мій погляд, прекрасно підходять для того, щоб почати їх використовувати у повсякденній роботі. Наприклад, я зробив пачку швидких дій у MacOS які конвертують картинки чи відео в різні формати, або ж роблять відео на швидкості ×2…×4, коли я роблю скрінкаст і демо роботи чогось, роблять чи розбирають PDF, зклеює картинки тощо (якщо цікаво, окремо покажу та розпишу приклади). Зокрема по цій схемі існує цілий застосунок AI-термінал — Warp. Так і Cursor активно взаємодіє з термінальними програмами.

Ідеально для R&D та малих проєктів Цей пункт випливає з попередніх. Це можливість швидко зібрати робочий прототип і протестувати чи все працює як задумано. І далі або розвивати далі створений інструмент чи викинути й попробувати щось робити інакше. Іноді навіть створити дашборд з візуалізацією ваших даних іноді навіть простіше і швидше згенерувавши сторінку на D3.js, ніж намагаючись зробити те саме в Екселі. Але важливо розуміти, що інструменти генерації коду, можливо, не роблять ідеальний код і тому його треба використовувати обережно у великих проєктах та проєктах, де важлива безпека.

Простіше починати одразу з коду, а не з макета у Figma Помітив за собою що вже не так хочеться робити макети у Фігмі, які потім потрібно якось ще переносити у код, і набагато простіше одразу почати роботу з кодом, отримуючи вже інтерактивний інструмент, замість придумування і малювання окремих версій усіх елементів. Так AI/LLM може понапридумувати аж занадто своєрідний стиль, особливо якщо не сильно описати бажаний результат, але за кілька ітерацій результат вдається стабілізувати. Тут у нагоді може стати подивитись як запит обробляє Firebase: детально описує стиль тексту та іконок, кольори, анімацію.

Результат обмірковування моделі перед створенням самого коду застосунку

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

Особливості роботи з генерацією коду

Написання документації та інструкцій Щоб Курсор чи інші моделі згенерували вам найбільш точний результат — йому потрібно якомога точніше описати, що вам треба. Тобто як і в класичному процесі розробки — створити документацію. І цей крок має бути першим. Це іноді трохи лінь робити, бо доводиться описувати наче очевидні речі. В принципі, для цього у тому ж Курсорі присутній режим Планування — на ваш запит і опис модель створює план (як звичайний ntrcnjdbq md-файл) з описом кроків. Що дає змогу почати. Або ж іти меншими кроками нарощуючи потрібні функції і потрібний вигляд саме почерговими запитами.

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

Що почитати

Українською не так багато матеріалів на тему, але оці цікаві:

• Технічна база для дизайну — те, про що соромно запитати у розробників. Для дизайнерів без досвіду розробки у цій статті від роз’яснення основ, до початку використання цього у роботі разом
• Cursor Rules: як навчити AI працювати з вашим проєктом. Поради по тоншому налаштуванню Cursor: використання правил .cursorrules, AGENTS.md тощо.

Душний p.s.

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

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