Нарешті це сталось. Я повністю перебрав, доповнив і опублікував статтю на DOU — «Принцип підстановки Барбари Лісков (про передумови, постумови та інваріанти)».

Спробував максимально розжувати те, що ж Барбара мала на увазі, додати конкретики та пройтися по кожному важливому пункту 🙂

У статті розповів про:
• принцип самої підстановки
• передумови та післяумови
• коваріантність і контраваріантність
• як з цим жити або як обійти

📌 Якщо ви вважали цей принцип незрозумілим — рекомендую до прочитання, адже я постарався навести реальні приклади коду та чіткі пояснення.

🙃 До речі, давно не писав у такому форматі, тож радий повернутися.

👇🏻 Діліться своїм досвідом у коментарях — цікаво почути, чи стало трошки зрозуміліше, що воно таке і з чим його їдять.

https://dou.ua/forums/topic/55754/

Друзі, продовжую низку неочікуваних новин 🙂 Давно хотілось створити подкаст, де говорити на менш технічні і на більш загальні теми в айтішці. Про професії, зони відповідальності, курйозні ситуації, ринок, проблеми, чи просто понити.

То ж вийшов перший пілотний випуск, в котрому спробували прояснити «Хто такий Delivery Manager»

Було дійсно цікаво поговорити з Олею, вона Delivery Manager із понад 10-річним досвідом у міжнародних компаніях.

📍 Якщо коротко, що затронули:
– чим насправді відрізняється Project, Product і Delivery Manager;
– як менеджери справляються зі стресом і факапами;
– чи потрібна технічна експертиза, щоб ефективно керувати командою;
– як виживає команда без менеджера та що не так із Jira;
– чи може штучний інтелект замінити менеджера.

🎥 Випуск уже на каналі
Переходьте, дивіться, ставте запитання в коментарях і буду дуже вдячний за ваш зворотній звʼязок

https://youtu.be/RGyYU2fhDtY

Записали черговий подкаст для FWDays PHP Talks з Павлом і Йожефом. Цього разу копнули Event Driven архітектуру.

Почали з основ — навіщо це все придумали, а потім розібрали три стовпи Event Driven: Event, Producer та Subscriber.

📍Ну і, звісно, поговорили про вузькі місця:

• Хто створює черги — продюсер чи сабскрайбер?
• Як правильно налаштовувати конфіги?
• Що робити з навантаженням і скейлінгом воркерів?
• І найболючіше — коли падають воркери, у тебе починає деградувати вся система.

Плюс затримки. Ті самі затримки, від яких нікуди не подітись 😅

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

Переходьте, дивіться, пишіть вашу думку і фідбек — буду радий подискутувати 🙂

https://youtu.be/SNplV4BaKvU

Чому я почав вести YouTube? 🎬

А чи має бути причина?

Ніби без причини щось не має сенсу. Чому, коли хочеться спробувати щось нове, ти одразу шукаєш, пояснення, мотивацію, а іноді і виправдання?

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

Мені подобається говорити, спілкуватись, ділитись думками, записувати подкасти, знайомитись з людьми з індустрії, отримувати фідбек, як позитивний, так і той, після якого хочеться рости.

І цього достатньо.

Не шукайте «чому». Коли всередині є справжнє бажання — це вже і є причина

https://youtube.com/@beercodeit?si=ZHLpe7xaN3eGQfqo

Друзі, маю для вас новий випуск на своєму каналі 🚀

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

В гостях був Томош – Cloud DevOps інженер, який погодився простою мовою пояснити, за що йому платять гроші 😁

📍 Якщо коротко, про що поговорили:

– Чому насправді "не буває Junior DevOps" і звідки тоді вони беруться?
– SysAdmin, DevOps, DevSecOps, FinOps – у чому різниця і де чия відповідальність?
– "Лінивий DevOps" – це хороший DevOps?
– Що бісить девопсів найбільше?
– Наскільки глибоко DevOps має знати код (Python, GoLang) і чи важливі soft skills?
– Вплив ШІ: як Copilot, Grok та Claude вже змінюють підходи до інфраструктури та автоматизації

Переходьте, дивіться, і, звісно, діліться своїми історіями та запитаннями в коментарях. Буду дуже вдячний за ваш зворотній звʼязок!

https://youtu.be/s-TTevLwMPA

Друзі, вийшла друга частина розмови Fwdays PHP Talks про DDD! 🎥

Разом з Йожефом Гісемом та Ігорем Проніним продовжили говорити про те, як бізнес і розробка можуть нарешті порозумітися 🙂

У цьому епізоді:

💬 про те, як знайти спільну мову між бізнесом і девелоперами — щоб усі рухались в одному напрямку, а не говорили різними мовами

🧩 коли реально варто використовувати Event Storming і контекст-мапи — і як ці штуки допомагають розкласти складну систему по поличках

⚙️ Value Object, Entity та Rich Model — не просто теорія, а як це працює у живих проєктах

Якщо тема DDD тобі близька — обов’язково глянь випуск і поділися своїми спостереженнями в коментарях 👇🏻

https://youtu.be/AnicWaTTvLg?si=4PFnfL_SLmBRL6AM

Звільнення

Мабуть, одна з найбільш табуйованих і неприємних тем у менеджменті.

Зізнавайтесь, чи бачили ви співробітника, якого "тягнуть"?

🤔 "А раптом він виправиться?", "Шкода людину", "Може, це я погано пояснив?".

Я проходив через ці сумніви. Але правда в тому, що коли ви не звільняєте неефективну людину, ви руйнуєте команду зсередини.

👉 Тому у новому відео вирішив підняти цю важку тему і розкласти все по поличках:

• Чому ми насправді боїмося звільняти (і до чого тут емпатія)
• Оцінка 360 та 9-box model: як зрозуміти, хто "тягне", а хто ні
• Токсичність, чому це бомба сповільненої дії
• Performance Improvement Plan (PIP)
• Покроковий скрипт, як повідомити про рішення, щоб це було професійно

Звільнення - це, мабуть, найскладніше рішення для менеджера. Але іноді - найправильніше

Тому дивіться відео, там багато практичних інсайтів: https://youtu.be/lZ-a_LzJXhU

Буду вдячний за зворотній звʼязок

#manager #teamlead #youtube

Ну що, йдемо в еру ШІ

Давно не писав сюди, але сьогодні зʼявився привід

Буду чесним, з php розробника я давно перекваліфікувався в менеджера, трошки golang розробника, пробував писати всякі речі на python та звісно мене затягнуло в agentic engineering.

👉 Вже доволі давно використовую Claude Code - ще до того як це стало мейнстрімом. За цей час зібрав купу практичного досвіду: власні pet-проєкти, впровадження в процеси розробки, агентні воркфлоу котрі можуть нескінченно покращувати продукт, ревью власних PR, тощо.

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

💬 Тому загорівся ідеєю створювати навчальні матеріали і продукт на основі власного досвіду.
Та перед тим як писати програму - дуже хочу почути вас.

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

3 хвилини, всього 9 питань, я буду щасливий, а ви отримаєте віртуальний бал і плюс в карму

👇 Посилання

https://forms.gle/rUzZ7qsD16MMZiEPA

Анкета анонімна і не до чого вас не зобовʼязує

Так, AI замінить тебе

Але тільки якщо ти залишишся там де ти є зараз

Попередню анкету заповнили 127 людей, (за що я неймовірно вдячний кожному і кожній хто долучився), і 65 з них написали про найпоширеніший страх, що AI їх замінить.

І дійсно, є задачі, які він робить краще і швидше за розробника. Бойлерплейт, шаблони, тести, конфіги, з цим важко сперечатись.

📍 Сьогодні 4% всіх публічних комітів на GitHub - вже написані Claude Code. Прогноз на кінець 2026, що це буде 20%

AI пришвидшує набір коду, але інженерія не тільки про генерацію коду - це про мислення (аналіз, пошук і вирішення проблем, архітектуру, прийняття рішень, розуміння того, що відбувається). Генерація коду стала дешевою, умовний PoC тепер можна зліпити за вечір, і це має повпливати на сам продукт. Логічно, що конкуренція зміщується на рівень ідей, UX, адаптації під конкретного юзера.

Історично ми проходили через це кілька разів, памʼятаєте як ми писали код?

• Спочатку все в одному файлі, один скрипт на 3000 рядків
• Потім зʼявились паттерни - розділили відповідальність
• Потім фреймворки - абстрагували рутину
• Потім модулі чи мікросервіси - розділили на контексти
Така сама еволюція відбувалась на рівні мов програмування: ассемблер, компілятори, no-code рішення замінять розробників 😅

👉 Кожен крок пришвидшував написання коду і підіймав планку мислення, а те, що відбувається зараз - це просто наступний етап

📍 Борис Чорний (напевно так правильно), чувак котрий створив Claude Code (доречі одесит), каже, що з листопада 2025 не написав жодного рядка коду руками, всі 100% пише AI. І його фокус змінився на те ЩО він будує, а менше на ЯК (залишу посилання на цікавий подкаст з ним)

📍 Андрій Карпати, один з засновників OpenAI, назвав цей підхід «agentic engineering» замість «vibe coding». Бо vibe coding - тупо генериш і апрувиш, а agentic engineering - це коли оркеструєш агентів, контролюєш якість, розумієш що під капотом.

Моя порада - не вірте заголовкам «AI замінить всіх». Але і не ігноруйте. Вчіться ревʼюїти швидше, вчіться проектувати складні системи, заглиблюйтесь в продукт і архітектуру. Ви маєте бачити систему повністю, а не на рівні окремої таски

Виглядає так, що інженери будуть переважати над monkey coders ще сильніше ніж зараз. І це круто.

#ai #engineering #career

Інструментів дуже багато і не зрозуміло чим користуватись

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

Проблема всіх інфлюенсерів в тому, що ніхто не пояснив ЯК з цим працювати, всі тільки кажуть ЩО юзати

❓ Основне питання не в тому "який інструмент кращий", а в тому яку задачу ти хочеш вирішити, адже можна мати найкращий інструмент і використовувати його на 10%

Рецепт такий, запитуєш себе - що я хочу зробити? Це може бути

• Фічу з нуля
• Рефакторинг великого проекту
• Розібратись в чужому коді
• Задебажити проблему, тощо

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

❗️ Без контексту будь-який інструмент генерує сміття. Так само, як і будь який розробник, якщо не задає питання "навіщо?". То ж не варто очікувати більшого від AI агента

З чим точно варто визначитись:

✅ Інструмент в якому пишеш код, з автокомплітом, підказками, дрібними генераціями. Обери один, звикни, налаштуй під себе, вивчи вже ті кляті hot keys, не важливо це Cursor, Windsurf, чи продукт від JetBrains - будь-що

✅ Coding assistant (agentic tool) для задач, коли тобі треба не рядок змінити, а фічу написати, протестувати і задеплоїти. Тут варто розібратись що таке Agentic Loop

observe → think → act → repeat

Агент дивиться на контекст (CLAUDE.md, spec файл, код, документація, тощо), думає що робити, робить, валідує і повторює поки не буде ідеально. Особисто я використовую Claude Code і всім раджу, проте, багато хто використовує аналоги і задоволений. Знов ж таки, проблема не в інструменті, а в тому, як ти підходиш до виконання задачі, чи розбиваєш на дрібні частини, чи знає агент про твої стандарти, чи достатньо чіткі вимоги до того, що ти хочеш отримати на виході

✅ Оркестрація

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

📍 Що ігнорувати без жодних сумнівів
На першому етапі ігноруєш всі інші інструменти котрі виходять щотижня, всі порівняння "X vs Y vs Z", тренди, котрі починаються зі слів "революційний підхід" і "прорив 2026". Якщо ти не розібрався з хоча б одним інструментом - тобі не потрібен другий.

Побудуй процес. Опиши задачу в spec файлі, винеси повторювані дії в скіли, додай контекст через CLAUDE.md (або аналог), визнач стандарти і конвенції. І в цей момент ти починаєш отримувати передбачуваний результат

👉 Головний напрямок для розробників це перехід від "vibe coding" до agentic engineering та spec-driven підходу.

Хвилинка самореклами 😁

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

Набираю першу групу до 20 людей, програма з особистим залученням та менторським супроводом

Заповни анкету - я звʼяжусь з тобою особисто https://forms.gle/HixRnG3GF2KmaL6y6

#AI #agents #tools #architecture

Записали 19 випуск FWDays PHP Talks

Цього разу з Йожефом та Віталієм Івановим (техлід в Spryker) поговорили про AI в розробці.

Побачив цікаву статистику - 87% людей на планеті ще не написали жодного промту до AI. Жодного. Тобто навіть не пробували. І тільки 0.01% щось намагаються будувати для бізнесу за допомогою АІ (тобто не тільки девелопмент)

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

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

📍 Ще розібрали чому класичний RAG (це коли ти даєш моделі додаткові дані з бази знань, щоб вона відповідала точніше) не завжди є ефективним рішенням, і що приходить на зміну

Коротше, якщо працюєте з AI або тільки починаєте - рекомендую подивитись. Година часу, але дуже насичена

Буду вдячний за фідбек 🙂

https://www.youtube.com/watch?v=ksU0V625GBQ

#AI #PHP #podcast #fwdays

AI Workflow

Багато розробників вже пробували AI в роботі, але по даним опитування на stack overflow довіра до того, що AI генерує, впала з 70% до 60% за 2025 рік. Чому? Бо підхід "кинув в чат - отримав результат" показує себе не кращим чином

👉 Але якщо побудувати pipeline, де кожен етап має свій контекст і свої перевірки - картинка змінюється. Спочатку аналіз задачі і генерація вимог, потім дизайн в Figma - щоб побачити візуально ще до першої строчки коду, потім імплементація з тестами і обовʼязково код-рев'ю

Тобто AI не просто "генерує код", він аналізує, проектує, верифікує і рев'юїть і все це в циклі, котрий відвторює SDLC

📍 Закинув відос де показую весь цей цикл на прикладі, то ж переходьте, дивіться, буду вдячний за фідбек 🙂

https://www.youtube.com/watch?v=4uLqamwjl-w

#ai #claudecode #workflow #sdlc

Як працює coding assistants під капотом

Коли ти даєш coding assistant задачу типу "виправ баг, ось error message" - всередині відбувається приблизно те саме, що робив би розробник. Спочатку треба зібрати контекст - зрозуміти що за помилка, де вона в коді, які файли залучені. Потім сформувати план і виконати дію - оновити файл, запустити тест, перевірити результат

❗️Але певні кроки вимагають від моделі взаємодії з зовнішнім світом - прочитати файл, запустити команду, підтягнути документацію, а мовна модель сама по собі цього не вміє. Модель приймає текст на вхід і віддає текст на виході. Якщо ти напряму запитаєш в чат "що написано у файлі main.go?" - вона скаже, що не має доступу до файлової системи

Сoding assistant як раз вирішує цю проблему. Перед кожним запитом до моделі він додає опис всіх своїх інструментів у вигляді JSON Schema. Кожен tool описаний структуровано - назва, що робить, які параметри приймає і якого типу. Щось типу:

{
  "name": "read_file",
  "description": "Reads contents of a file",
  "input_schema": {
    "type": "object",
    "properties": {
      "file_path": { "type": "string" }
    }
  }
}

Модель отримує цей список і тепер знає що в неї є ReadFile, WriteFile, RunCommand, Grep і так далі. Коли їй треба щось зробити - вона відповідає не звичайним текстом, а спеціально структурованим блоком. Відповідь від моделі може містити кілька блоків одночасно - текстовий блок (пояснення для тебе) і tool_use блок (інструкція для assistant-а). Виглядає приблизно так:

{
  "content": [
    { "type": "text", "text": "Зараз прочитаю файл..." },
    { "type": "tool_use",
      "id": "call_abc123",
      "name": "read_file",
      "input": { "file_path": "main.go" }
    }
  ],
  "stop_reason": "tool_use"
}

👉 Зверни увагу на stop_reason: "tool_use". Це сигнал для assistant-а - модель ще не закінчила, вона хоче виконати інструмент. Assistant бачить це, витягує з tool_use блоку назву функції і параметри, виконує дію (читає файл з диска), і відправляє результат назад з тим самим id щоб модель зрозуміла до якого саме запиту це відповідь:

{
  "type": "tool_result",
  "tool_use_id": "call_abc123",
  "content": "package main\nfunc handler()..."
}

Модель отримує вміст файлу, аналізує його, і далі або відповідає завершити (stop_reason: "end_turn"), або робить наступний tool call. І так по колу

Ось як це виглядає покроково:

https://lms.beerphp.club/files/coding-assistant.png

Як модель вирішує який саме інструмент викликати

Вона орієнтується по description в JSON Schema. Саме текстовий опис tool-а - це те, на основі чого модель приймає рішення "мені зараз потрібен grep, а не read_file". Якщо два інструменти мають схожі описи - модель починає плутати їх між собою і викликає не той. За даними Anthropic, якщо дати агенту доступ до 18 інструментів замість 4-5 - якість вибору помітно падає, бо модель має зважити занадто багато варіантів одночасно

Що це цам дає?

📍 Можливість виконувати складніші задачі

📍 Розширюваність. Coding assistant легко отримує нові інструменти через MCP (Model Context Protocol - окремий протокол для підключення зовнішніх тулів). Ти описуєш новий інструмент тією ж JSON Schema, підключаєш сервер, і модель одразу починає ним користуватись

📍 Точність. Замість того щоб індексувати весь твій codebase і відправляти його на зовнішні сервери, assistant шукає потрібний код через tool calls - читає конкретні файли і grep-ає по кодовій базі, звужуючи контекст

👉 Тому звертайте увагу на кількість тулів, обовʼязково на якість їх описів, в ідеалі аналізуйте флоу через котре проходить агент під час виконання задачі, адже зайві кроки з його боку забруднюють ваш контекст і знижують якість вирішення задачі

#AI #agents #tools #architecture

MCP vs CLI

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

📍 MCP-сервери можуть з’їдати до великий відсоток вашого контекстного вікна просто за описи інструментів (фактично JSON-схеми). В той час як CLI мінімум вдвічі дешевший

📍 Надійність: CLI це бінарник котрий робить один прямий виклик, а MCP завжди має сервер, який може стати додатковою точкою відмови

📍 Виявилось, що LLM натреновані на купі даних у відкритих джерелах, де CLI команди писали мільйон разів, в документаціях, прикладах, readme і т.д. і що наші моделі можуть просто знати, як працювати з конктетною тулзою

🎥 Закинув відео, де розібрав як воно працює під капотом, чому MCP програє в ціні, але де він все ще залишається незамінним в певних ситуаціях. Переходьте, дивіться, буду вдячний за фідбек 🙂

https://www.youtube.com/watch?v=9Tu8usEv8EU

#ai #mcp #cli #claudecode #perplexity #engineering

Claude і third-party tools

❗️Борис Чорний (той хто розробляє Claude Code), написав в соц мережах:

Починаючи з завтра, 12:00 PT (тихоокеанський час) підписки Claude більше не покриватимуть використання через сторонні інструменти типу OpenClaw.

Ви й далі зможете користуватись цими інструментами через свій Claude логін за допомогою додаткових usage bundles (зараз доступні зі знижкою), або через Claude API key
Ми активно працювали щоб відповідати зростаючому попиту на Claude, і наші підписки не були розраховані на патерни використання цих сторонніх інструментів. Capacity - це ресурс котрим ми розпоряджаємось обдумано, і ми пріоритизуємо клієнтів котрі користуються нашими продуктами та API

Підписники отримають одноразовий кредит рівний вартості місячного плану. Якщо потрібно більше - тепер можна купити usage bundles зі знижкою. Щоб запросити повний рефанд - шукайте лінк у пошті завтра

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

❓Що це значить?

Якщо юзаєш Claude через сторонні інструменти типу OpenClaw через OAuth - підписка це більше не покриває (але тут непрозоро, чи за це буде бан, чи які санкції).

Або купуєш usage bundles (за додаткові кошти), або переходиш на API key і платиш за токени. Також поки не дуже прозоро, як це вплине на інтеграції з VS Code чи плагінами для браузерів, бо під third party вони також попадають.

Якщо юзаєш Claude тільки через офіційні продукти - тебе це взагалі не торкається 😅

Джерело

#claude #anthropic #ai

Як підняти свого персонального асистента claude + telegram

Нещодавно створив собі персонального асистента. Працює 24/7 на сервері за 6 баксів. Я пишу йому в Telegram - він відповідає, може перевірити код, сформувати задачі, зайти в календар. Круто те, що це повноцінний Claude Code з доступом до всього що я підключив

🔥 Коли обкатав PoC, створив чотирьох таких девелоперів 🙂
Зняв про це відос https://youtu.be/Nioa8ZBzDqE

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

https://telegra.ph/Claude-Code-na-VPS-%D1%96nstrukc%D1%96ya-04-11-2

Сподіваюсь ідея зайде та хтось знайде для себе застосування 🙂

Якщо подібними речами тре ділитись частіше - накидайте коментарі, буду вдячний за фідбек 👋

Youtube | Instagram

Пост вдогонку до попереднього

Кілька котрибьюторів (українців) зробили кльовий патч для телеграм плагіна

https://github.com/k1p1l0/claude-telegram-supercharged

👉 Має дійсно круті фічі, можна відправляти voice messages (для цього на VPS має бути whisper), генерувати telegraph для довгих повідомлень, керує памʼятью, підтримує топіки, якщо додати бота в групу і т.д.

Може не супер зручно що до оновлень, та менш із тим, крута ініціатива

Youtube | Instagram

Claude Code оновив desktop версію

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

Скоріш за все термінальна версія все одно буде швидше імплементовувати нові фічі. Чує моє серденько, як би плагін для VSCode не став скоро 3rd party рішенням доступним тільки по API :)

Youtube | Instagram