#ПомічникШІ

Нарешті я дістався до MCP. Довгий час вІдкладав, бо це виглядало достатньо складно. Плюс, мені більш-менш вистачало того, що агент здатний досягнути з одними лише командами оболонки. Але, підійшов вдалий момент.

Для тих, хто не знає, MCP (Model Context Protocol) - це спосіб дати агенту ШІ нові інструменти. Типовий агент з коробки вміє редагувати файли, виконувати команди оболонки та шукати в інтернеті. А шляхом MCP до нього можна додати буквально будь-які функції.

Для того нам потрібний сервер MCP. Це допоміжна програма, яка спілкується з оболонкою агента пакетами JSON. Оболонка запускає сервер, забирає з нього набір доступних дій, та робить доступними для агентів. А коли агент звертається до певної дії, передає команди сервера MCP та той їх виконує. Сервер MCP є звичайною програмою та отримує доступ до локальних ресурсів — наприклад, може прочитати файл конфігурації. Також сервер запускається надовго, а значить, може мати власний стан — чи навіть підключення до інших сервісів.

Все це звучить помірно цікаво, якщо мова йде про загальні MCP. Ну може, такий, що вміє надсилати пошту. Ще й з чужим кодом всередині.

Але ось моя головна думка тут: не обовʼязково шукати чийсь незрозумілий MCP. Ти завжди можеш згенерувати собі свій, під конкретні обставини та задачі. Так, я відразу кажу “згенерувати”, а не “написати”, бо писати власноруч сенсу мало. А агент цілком здатний згенерувати MCP за твоїми вимогами.

Мій приклад такий: хотілося мати консоль Rails на стейджингу. Тоді значно спрощується перевірка невидимих частин логіки, бо агент може це робити власноруч. (Ба більше, оскільки він знає код проєкту, то що писати в консоль, теж добре розуміє.) Отже, згенерував MCP, який і знає, як на стейджинг потрапити, і де взяти ключі. Зручно надзвичайно.

ОК, ще більше заглиблююся в переконанні, що власні, доморощені MCP підіймають роботу з агентом до наступного рівня ефективності.

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

Але навіть так, робота з Jira залишалася нудним та неприємним обовʼязком. Тому (і це починає бути патерном), відкриваю Cursor і кажу: ось в мене є acli, давай, проаналізуй все що мене стосується.

Він поколупав документацію до acli всілякими викликами acli jira --help і так далі. Потім витягнув десь ті ж самі результати, що і я раніше. Але різниця в тому, що LLM на ходу може згрупувати ці результати, оформити, та робити над ними дії. Так, перше, що я зробив — це сказав “переведи все, що в Ready for Release понад місяць, у Closed”. (Інфраструктурні задачі самі не закриваються.) І оце вже дійсно потужно!

Поробив ще трохи, а потім кажу — ми тут розібралися, як працювати з Jira через acli, збережімо інструкцію в файл. (Це дуже корисний хід, часто так роблю.) А потім думаю… ну якщо вже інструкція є — зроби з неї кілька команд. То й зробив на кшталт /jira-my-tasks і так далі.

От сиджу сьогодні з тими командами, але річ у тім, що команди (наскільки я знаю) запускаються явно мною, а не агентом в процесі інших операцій. Тож, нарешті, кажу “а тепер — роби з команд MCP!” Ну то й він зробив малесенький MCP на Python, який вміє робити ті самі виклики acli.

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

Ще тут висновок. LLM найкраще розкриваються там, де багато контексту, складна послідовність дій. Поки ти робиш одиничні зміни — може так виглядати, що LLM це зайве ускладнення, та, певно, так воно і є. Тому раджу пробувати задачі вищого порядку — сміливіше!

Рівно два роки тому (навіть не знаю, як такі збіги відбуваються! магія!) я писав про керування водяним охолодженням — а саме, програму FanControl для Windows.

Досі нею користуюся, програма гарна. Я її запускаю як сервіс за допомогою іншої чудової програми - Non-Sucking Service Manager (NSSM). NSSM вміє будь-яку програму зробити системним сервісом — а значить, вона не буде маячити на робочому столі та буде надійно запускатися та перезапускатися.

От тільки змінювати конфігурацію такої загорнутої FanControl стало незручно. Треба зупинити сервіс, відкрити у звичайному режимі, відредагувати, закрити, запустити сервіс наново… А ще вона ж не під головним користувачем системи, а під адміністраторським. А Windows не дає одночасно зайти двома користувачами, тож потреба все зупинити перетворює навіть тривіальну зміну в справу хвилин на 20.

Звучить як ідеальна задача для агентів! В мене вже налаштований SSH, то й кажу “от комп, на ньому FanControl, збільш стартову швидкість помпи на 3%.” Хотів перевірити, чи воно зрозуміє стільки деталей.

З SSH проблем ніяких. Чудово, що агент розуміє командний рядок Windows та PowerShell значно краще за мене. (Окрім: SSH не мав authorized_keys. А для того, щоб агент зробив все, потрібний безпарольний доступ. та виправлення цього навіть з агентом зайняло значно більше часу, ніж решта справи. Як завжди. Але принаймні це разове покращення.)

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

Місце, яке треба змінити, агент теж знайшов серед багатьох профілів вентиляторів. Конфігурація у JSON, зате потрібний параметр є однією з двох координат ламаної функції на кшталт ["50,35", "70,100"] - що значить, до 50 градусів увімкнути помпу на 35 відсотків, до 70 поступово збільшувати до 100, та там і тримати. От, агент зрозумів, що перше значення потрібно замінити на 50,38. Ну, за тим він почав вигадувати скрипти PowerShell для часткової заміни рядка в файлі, що ніяк не виходило. Аж поки я не сказав “та скопіюй вже файл на нашу машину, виправ та поверни на місце”.

Ну й з перезапуском сервісу все зовсім просто та прямолінійно.

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

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

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

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

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

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

Коли я починав користуватися Курсором, в оточенні агенту не запускався Ruby. Тому кожний тест чи іншу команду я власноруч запускав в терміналі, а потім копіював в чат. (Ну, ще раніше я ще й команди сам писав та обирав, що саме скопіювати.)

Звісно, потім я це полагодив. Проте, оскільки я остерігався дозволити агенту запускати все підряд, то сидів та погоджував кожний rspec. А ще нагадував агентам проганяти rubocop - зазвичай вже після того, як на CI впало.

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

Щоб такого уникнути, вдався до кількох мір. Ні, я досі не збираюся дозволяти агентам повну свободу. Натомість опановую allowlist. Це перелік команд, які дозволено запускати автоматично, без погодження. Цікаво, що allowlist містить префікси кожної команди, тож можна туди додати комбінації на кшталт bundle exec rspec.

В allowlist критично важливо запхати всі команди, які не потребують справжнього рішення з мого боку. От, якщо будемо видаляти базу в продакшні — тут я краще подивлюся. А тести, лінтер, дрібні команди збірки та організації по типу git - усі роблю дозволеними.

(До речі, саме Ruby в мене не працює в sandbox, бо доступу до зовнішніх файлів. Тож це не вихід)

Як виявилося, в Cursor цей allowlist сидить в базі SQLite, тож його не так легко відредагувати напряму. А хотілося саме напряму, тому навайбкодив скрипт, який переганяє allowlist з простого текстового переліку в налаштування.

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

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

Тепер я можу залишати Cursor на довгі проміжки часу та отримувати вагомі результати. (Звісно, це після фази планування — про яку теж можна окремо.)

Знаєте трикутник “дешево, швидко, якісно: обери два”?

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

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

Але. Ніхто такі зміни не брав в продукт на віру! Яким би визнаним та досвідченим інженером ти не був, нормальна практика була почитати той код, та якщо він виявився погано структурованим та незрозумілим - попросити доробити, впорядкувати, і таке інше.

До речі. Раніше взагалі тільки круті інженери могли видавати код, що працює, з такою швидкістю. Тому, гадаю, раз LLM пише код ну настільки швидко, ми опиняємося під впливом гало-ефекту та високо ставимося до її розуміння теж. Втім, за досвідом, результат більше нагадує зграю мало оплачуваних, зате завзятих кодерів з прямим підключенням до Stack Overflow.

(От вам щеплення від гало-ефекту - ставтеся до агента не як до rockstar 100x developer, а як до найманої команди фрілансерів з біржі. Бо воно, бляха, так і є, якщо подумати.)

Та звісно ж, питання було риторичним. Тільки чому? Не тому же ж, що нам за нього платять, та страшно, що буде, коли LLM здатна видавати тисячі рядків коду на будь-яку примху. (Втім, сподіваюся, тобі насправді платять не за код, а за розуміння. Але про те не сьогодні.)

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

Я от тільки вчора згенерував з телеграм-каналу інформаційний сайт. За пів години. Код взагалі не бачив. Причому тут два шари згенерованого коду: спочатку скрипти для збору та впорядкування змісту, а потім вже власне сам сайт. Оце для мене чудовий — чарівний навіть — результат LLM.

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

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

Бо LLM більше “грає в хорошого розробника”, це буквально, що воно робить, бо це ж семантична папуга, розумієте? Вона не знає, як правильно, в неї немає сенсу смаку.

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

Я не вірю, в широкому сенсі, що можна обмежити власну увагу планами та специфікаціями та залишити шар коду суто для ШІ. Не виключаю, що певним чином можна переконати LLM писати гарний код, але для цього потрібно принаймні її для того інструктувати. Та якщо у тебе виходить, напиши, будь ласка, i am trapped in an LLM prompt please send help.

Коли людина робить щось не так, як тобі хотілося б, ти просиш її робити інакше, та людина запамʼятає це на наступний раз. (Ну, як правило.) От з LLM надважливо не запозичити цей підхід та не виправляти LLM, бо ти марнуєш час (та гроші) на покращення тільки поточного результату. В LLM антероградна амнезія, та інший раз вона зробить по-старому.

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

Отже. Коли LLM робить щось не так, як тобі хотілося б, найкраще це повернутися до початку та виправити інструкції. Взагалі тут два варіанти є.

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

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

Тож, покращуємо початковий запит - чи план - та починаємо наново.

Або LLM не знає про наші загальні вподобання. Я хотів логіку в сервісному шарі, а ти написала все в моделях. Чи я завжди роблю стилі з shadcn/ui. Чи процедурні питання: запускай тести після кожної зміни. Чи по стилю: я полюбляю функції до 20 рядків та винесення літералів у константи.

Коли до згенерованого коду зʼявляються такі претензії, ще більше варто не виправляти на ходу, а відкрити SKILL.md та написати, як любиш. Мене особисто така зміна рамки відновлює інтерес до роботи. Замість нескінченних виправлень одних та тих самих дрібних негараздів я розробляю комплект навичок. А це вже моя улюблена аналітична задача: помітити, що не так, узагальнити, знайти рішення. Ще й свої вподобання починаєш краще розуміти.

🎂📢🛫 Та в мене черговий збіг! Рівно чотири роки тому я почав цей канал, і сьогодні відновлюю щоденні пости. Досвід проситься назовні!

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

Звісно, все, що LLM вміє — це генерувати текст. Але текстом може бути що завгодно. Не код, а план реалізації.Чи план всього проєкту? Рецензія на код? Історія змін? Журнали? Метрики? Чати з менеджером? Чати з самою LLM? Команди для адміністративних операцій?

Наприклад. Сидимо ми на відеодзвінку з Данилом, аж як помічаю, що дзвінок гальмує, бо CPU зашкалює. Починаю дивитися, що до чого - Activity Monitor, htop тощо. І тут Данило пропонує — а доручи це агенту. Доручив! Агент виконав кілька команд та відразу запримітив, що справа навіть не в CPU, а в RAM. Недостача памʼяті призвела до жорсткого використання свопу. До того ж він відразу запропонував, які застосунки варто зупинити — та навіть міг сам це й зробити, не виходячи з чату.

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

Інший приклад. Шукаємо причину активної помилки в продакшні. Ситуація горить. Можна шукати логи та скидати потроху LLMці. Або питати її, де в коді є релевантні місця. Але можна прямо сказати: в мене така-то ситуація, нумо розв’язувати. Та вона дуже компетентно почне це робити! Особливо якщо ти навісиш достатньо корисних MCP - можливо, згенерованих під власні потреби. Це теж потребує уяви.

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

В далекому 2023 році я витратив чимало часу, щоб зробити красивий пост про похід на Клаферкесель з анімованою картою та журнальним форматом. Витратив… і зрозумів: на другий такий в мене нескоро буде час. Зокрема підгодування карти та треків було рутинною роботою, та ще й вимагала серйозної математики. У 2025 я спробував щось відтворити, напоровся на баги з проєкціями та знову відклав.

Та ось… Цього разу взявся за справу із Курсором. І воно пішло! LLM легко порається з задачею “зроби мені карту по аналогії, але іншого місця” - тут я був впевнений.

А що здивувало, так це те що Курсор достатньо візуально обладнаний, щоб вручну налагоджувати проблеми з вирівнюванням текстур та розташуванням обʼєктів на карті. А проблеми були суттєві. От він брав, рендерив кадри з різними версіями, та перевіряв. Наприклад, наклав координати міст України на текстури Європи — та помітив, що міста не на місці. Серйозно вражає. Я гадав, що ми будемо робити це в парі — моїми очима — а потреби не було.

Та друга ручна задача: підчистити GPS-треки прогулянок для мапи. Та хоча б підрізати. Тож я скористався трюком: згенеруй мені редактор для того, щоб обрізати ці треки по довжині. І він згенерував! (Дивись ілюстрацію.) Та я за пʼять хвилин встиг закінчити цю роботу, жодного разу не дивившись в файл з координатами.

Або ще: локальна 3D-мапа в мене була квадратна, бо на це вистачило зусиль. Але кругла ж красивіше! Тож Курсор за один запит переробив квадратну на круглу (відредагував 3D-сітку, на яку накладаються текстури.)

Або ще краще: мені хотілося, щоб під час анімації на карті “їхав потяг”. Хтозна скільки б я це робив вручну, а тут встиг за годинку паралельно з іншими задачами. (А в старому пості тепер їде машинка з Відня, бо чому б й ні.)

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

Тож багато надії, що справа буде рухатися!

Результат ось: Що ми робили в Яремче. Краще дивитися на великому екрані, хоча для телефонів, я гадаю, ми з Курсором теж щось придумаємо, якщо піде. (Поки що я розробляв дизайн для моніторів, а на телефон лише підганяв, щоб мало хоч якийсь приємний вигляд.)