Стендап Сьогодні

Що я зробив, що я хочу зробити, і що це все значить.
Повсякденні здобутки в форматі стендапу.
Детальніше в статті

Підписатись на RSS
📢 Канал в Telegram @stendap_sogodni
🦣 @stendap_sogodni@shevtsov.me в Федиверсі

09.04.2026

LLM для дослідження

В моїй роботі найбільше користі від LLM навіть не в написанні коду, а в дослідженні та операціях.

Ну тобто код воно генерує — проте тут зміни кількісні, не якісні. Ну швидше генерує, ніж я пишу. Ну можна через це згенерувати більше коду, як всі ми знаємо. Але в цілому, цінність коду відʼємна, та впровадження LLM ніяк це не змінило.

Зате із дослідженням… Якщо дати агенту достатньо інструментів - CLI, API, MCP - байдуже — то він настільки вправно збирає дані та аналізує, як я по-людськи ніколи не зможу.

Наприклад, я не зможу витягнути з CloudWatch метрики різної роздільної здатності, за різні проміжки, зробити кореляцію та видати табличку. Точно не за розумний час!

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

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

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

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

08.04.2026

Приготування їжі наперед

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

Отже, що я дізнався.

Коли готуєш страву “пакетом”, наперед, то можна вкласти в приготування значно більше нюансів. Щодня я клав сирий перець — тут можна його протушкувати. Додати спецій (дізнався, що сушений часник + копчена паприка це чисто ароматизатор ковбаси!) Можна покласти щось особливе, таке що кожний день возитися не будеш.

Звісно, також воно й швидше виходить. Хоча поки готуєш, так не виглядає! Бо замість звичних двох кесаділь доводиться готувати всі десять. Але то лише перше враження.

Тепер приготувати сніданок — це дістати кесаділью з морозилки, покласти в холодний прес, увімкнути та… піти займатися власними справами. Вона спочатку повільно розігріється, а потім там же ж і підсмажиться.Отут дуже відчуваю, як багато часу звільнилося. Справжня якісна зміна життя!

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

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

Отже… Якщо в тебе є улюблений рецепт приготування наперед — поділись, будь ласка. А якщо ні - раджу теж спробувати.

07.04.2026

15 хвилин про bike shedding

В мене, якщо не писати щодня, прокидається бажання писати серйозніше, але не зараз, а коли буде час. (Ніколи.) Тож спробую нову тактику: нехай пост займає не довше 15 хвилин; є що сказати — ділюся.

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

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

От, проєктуєте ви JSON API. І все з ним зрозуміло. Але. Чи повертати поля результату на верхньому рівні {"foo": "bar"}, а може, загорнути в {"data": {"foo": "bar"}}, чи response, чи entity, чи все ж за назвою сутності {"fooser": {"foo": "bar"}}?

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

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

А от що дійсно важливо — то дбати про узгодженість в межах власного API.

13.03.2026

Як не бути рабом ШІ

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

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

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

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

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

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

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

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

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

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

12.03.2026

ШІ-вигоряння

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

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

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

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

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

03.03.2026

Знову з робочим ноутбуком

За два з гаком роки робота за стаціонарним Mac Mini мені добряче набридла. Цього тижня, нарешті, приїхав на заміну новий Macbook Pro (той що 14" на M5, якщо вам таке цікаве.) Здивувався, наскільки я цьому щасливий.

Для початку, я знову можу працювати на дивані! Чи на кухні! (Чи в гамаку!) Такі дрібниці, але як воно приємно. Особливо для дзвінків та інших неконцентрованих задач.

Нагадаю, що Mac Mini я завів щоб краще розділяти роботу та життя. Не працює. Певно, якби в мене був окремий фізичний офіс, то був би ефект. А поки цей робочий комп стоїть за тим же ж столом, що й “домашній”, в тій же ж кімнаті — не відчуваєш різниці. Тільки ускладнення. Хоча, окремий ноутбук для роботи в мене залишається. Розділення контекстів таким чином — і корисно, і безпечно.

Також я знову можу принести ноутбук в кафе чи до коворкінгу. Якщо спосіб життя не дозволяє з 9 до 5 сидіти за одним столом — то стаціонарне робоче місце тільки обтяжує. Отже, не з того почав! Хоча й розклад дня в мене у 2023 був більш спокійний.

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

З плюсів Mac Mini - хіба що його компактність. Тут питань нема. (Особливо з новішими моделями! Вони ж як Raspberry Pi!) А якщо хотіли огляду нового макбуку — здивував своєю товщиною, бо я вже звик до Air, а тут такий бутузик. Навіть значно товще за моделі з початку 2010-х. А так ну макбук та й макбук.

28.02.2026

Рівно два роки тому (навіть не знаю, як такі збіги відбуваються! магія!) я писав про керування водяним охолодженням — а саме, програму 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 для часткової заміни рядка в файлі, що ніяк не виходило. Аж поки я не сказав “та скопіюй вже файл на нашу машину, виправ та поверни на місце”.

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

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

22.02.2026

Zigbee: дійсно гарно

Коли я майже рік тому писав про Zigbee - то не мав ніякого досвіду. Відтоді в моєму розумному будинку зʼявився й цей протокол, тож ділюся враженнями.

По-перше, якщо в тебе вже є HomeAssistant, то підтримка Zigbee додається через USB-адаптер - наприклад, Sonoff ZBDongle-E. А не окремою коробочкою. Це відразу набагато краще коробочки, бо звʼязок HomeAssistant з пристроями Zigbee є безпосереднім та не покладається на Wi-Fi чи навіть Ethernet.

(Бо, якщо подумати, як Wi-Fi, так і всі протоколи з коробочкою-шлюзом ходять через роутер. Це і повільніше, і додає точку відмови.)

Підключення пристроїв безболісне та нагадує Bluetooth, тільки без кодів підтверджень. Відбувається прямо з HomeAssistant. Далі пристрій стає частиною мережі. “Мережа”, до речі, визначається ключами доступу — які дуже важливо зберегти. В мене один з пристроїв під навісною стелею, не хотілося б туди лазити, щоб привʼязувати його наново.

Також приємною несподіванкою було те, що мої лампи Philips Hue підтримують Zigbee. (І навіщо я той міст Philips Hue Bridge купував?) От прямо береш їх та спарюєш із HomeAssistant. Так само і пульти до тих ламп. Окрім простоти, воно стало надійніше.

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

Так що якщо ти вагаєшся, раджу вкластися один раз в цю екосистему — воно того варте.

21.02.2026

Я повернувся

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

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

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

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

В мене таких “складніших задач” безліч, як на роботі, так і для себе. От, сьогодні. Давно хотів зібрати відео наших танців з різних груп в телеграмі. Робити це вручну — я не витримаю. Писати для того скрипт вручну — витратити день на спроби, ще й без гарантії результату.

А LLM… За 10 хвилин діалогу зробило мені на Go утиліту, яка заходить моїм користувачем та завантажує всі відео з обраної групи. Та ще й з діапазоном дат та красивими іменами файлів. Ось код, я його навіть і не читав ще.

І задача розвʼязана. І день вільний. А якщо цілий день витратити, то можна прямо серйозний застосунок запустити — але про це не сьогодні.

23.01.2026

Як я робив MCP для Jira

ОК, ще більше заглиблююся в переконанні, що власні, доморощені 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 це зайве ускладнення, та, певно, так воно і є. Тому раджу пробувати задачі вищого порядку — сміливіше!

Раніше