{ "version": "https:\/\/jsonfeed.org\/version\/1.1", "title": "Здоровий глузд: дописи з тегом Gemini", "_rss_description": "Олександр Колодько. Інформаційний та навігаційний дизайнер. Співзасновник команди ARC, співзасновник та головний дизайнер в Агентах змін (А3). Пишу про дизайн і цікаве мені · alexkolodko.com · wayfinding.systems", "_rss_language": "uk", "_itunes_email": "", "_itunes_categories_xml": "", "_itunes_image": "", "_itunes_explicit": "", "home_page_url": "https:\/\/blog-archive.alexkolodko.com\/tags\/gemini\/", "feed_url": "https:\/\/blog-archive.alexkolodko.com\/tags\/gemini\/json\/", "icon": "https:\/\/blog-archive.alexkolodko.com\/pictures\/userpic\/userpic@2x.jpg?1768915547", "authors": [ { "name": "Олександр Колодько", "url": "https:\/\/blog-archive.alexkolodko.com\/", "avatar": "https:\/\/blog-archive.alexkolodko.com\/pictures\/userpic\/userpic@2x.jpg?1768915547" } ], "items": [ { "id": "164", "url": "https:\/\/blog-archive.alexkolodko.com\/all\/cursor-and-novibecoding\/", "title": "Cursor та (не)вайб кодінг", "content_html": "

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

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

\n\"\"\n<\/div>\n
\n\"\"\n<\/div>\n

Що цікавого можу відмітити за рік використання.<\/p>\n

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

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

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

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

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

\n\"\"\n
Результат обмірковування моделі перед створенням самого коду застосунку<\/div>\n<\/div>\n

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

Особливості роботи з генерацією коду<\/h2>\n

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

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

Що почитати<\/h2>\n

Українською не так багато матеріалів на тему, але оці цікаві:<\/p>\n