Чому Context Engineering важливіший за «гігантське контекстне вікно»?

У коментарях до попереднього відео був коментар «треба просто дочекатися моделей на 100 млн токенів».
В теорії гарно, на практиці - ні.

Чому? Дивимося відосик: https://youtu.be/1xNvEt8e-ek

Що таке "Агенти" в IDE, які вони мають проблеми і як їх фіксити

Розбираємо агентів у розробці: що це таке, чому їх так називають, як працює agent loop, що дають tools/MCP, чим відрізняються повністю автономні і Human-in-the-loop сценарії – і чому найбільша проблема це дрейф агентів.

https://youtu.be/TH-HG_dqVZk

Spec-Driven Development – новий тренд в розробці з агентами

Якщо рік тому найбільш гарячим топіком в розробці були агенти, то зараз - це SDD (Spec-Driven Development). https://youtu.be/lR0oEIRM5FI

Розказую про цей підхід і запрошую на воркшоп, який починається завтра увечорі, друга частина буде в суботу.

Лінк на воркшоп: https://fwdays.com/en/event/ai-cursor-workshop

Новеньке відео у мене на каналі про актуальні у 2026 році навички розробника під впливом GenAI

youtu.be/soZf9ZhBtQI

Частина 1: Базові навички GenAI Basics

1. Розуміння того, як працює GenAI:
Що таке моделі, токени, контекстне вікно
Що таке вектори та векторне представлення даних
Звідки беруться галюцинації і як їх мінімізувати
Чим реальна відповідь відрізняється від впевненої нісенітниці 🙂

2. Безпека, приватність та ризики:
Які дані можна відправляти в модель, а які ні
Режими «не тренуватися на моїх даних»
Анонімізація та маскування конфіденційної інформації перед відправкою в модель

3. GenAI як частина щоденної продуктивності:
Використання AI-ноутбуків / асистентів (типу NotebookLM) для навчання і досліджень
Робота з джерелами: підвантажити матеріали, витягти структуру, зробити майндмеп
Аналіз документів, реквайрментів, довгих текстів через LLM
Генерація листів, резюме, конспектів, чернеток по шаблонах, а не «з нуля руками»

Частина 2: Побудова рішень з використанням GenAI

1. Робота з API моделей:
Вміння звернутися до моделі через API (не тільки через інтерфейс чату)
Розуміння режиму стрімінгу: токен за токеном, а не чекати весь результат
Робота з лімітами запитів і throttling, щоб система не падала під навантаженням

2. Вартість і оптимізація:
Як порахувати, скільки токенів «з’їдає» запит
Кешування відповідей або проміжних результатів
Розуміння, коли нема сенсу ганяти найдорожчу модель

3. RAG та пошук:
Розуміння концепції Retrieval Augmented Generation
Векторний пошук: індексація, пошук по embedding’ах
Гібридний пошук: поєднання векторного і класичного пошуку по ключових словах

4. Агенти та оркестрація:
Що таке агент і agent loop
Як дати агенту tools / інструменти і для чого вони
Базова оркестрація: кілька агентів, їх ролі, послідовність кроків
Розуміння ризиків: дрейф агентів, накопичення помилок, як це контролювати

Частина 3: Інструменти розробника з GenAI (Agentic IDE, MCP тощо)

1. Використання agentic IDE не тільки як «автодоповнювача»:
IDE типу Cursor / Copilot / інші — не лише підказки, а саме агенти
Налаштування режимів: які моделі, які можливості, що їм дозволено / заборонено

2. Керування контекстом у проєкті:
Відключення зайвих файлів від індексації (і з точки зору приватності, і якості)
Розуміння, як IDE індексує проєкт і що додає в контекст до запиту
Вміння вручну додати потрібний контекст, якщо автоматична магія не вивозить

3. Rules / інструкції / промти:
Налаштування правил для проєкту (style guide, архітектурні обмеження, підходи)
Використання команд / шаблонів промтів, прив’язаних до проєкту
Формування власної «бібліотеки промтів», а не кожен раз придумувати з нуля

4. MCP та зовнішні інтеграції:
Розуміння, що таке MCP-сервер і MCP-tools
Вибір мінімально необхідного набору tools під конкретну задачу
Усвідомлення, що «включити все підряд» тільки шкодить якості рішень

5. Ефективна робота з агентами в IDE:
Коли варто запускати агента, а коли дешевше зробити руками
Як ставити задачі, щоб агент не наробив зайвого сміття по всьому репозиторію
Розуміння підходів типу Spec-Driven Development у зв’язці з агентами

6. Cost-менеджмент:
Скільки реально коштують «запуски на макс» у IDE (моделі, контекст, агенти)
Як не спалити місячний ліміт за один день ентузіазму
Баланс між зручністю, якістю відповіді і вартістю токенів

Сьогодні відосик нетиповий для каналу, але які часи - такі й відосики.
До речі, хто знає відповідь на питання про газ для балонів у Львові - прохання напишіть в коментарях :)
https://youtu.be/lY6JF6IZr04

⚙️ Node.js — це про універсальність, масштабування та великий вибір готових рішень, тому опанувати Node.JS = перейти на новий рівень у розробці, карʼєрі та зарплаті.

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

Опанувати один з найпопулярніших інструментів веб-розробки, що дозволяє фронтендеру писати бекенд, налаштовувати взаємодію з базами даних, розгортати інфраструктуру і тестувати середовище, ― можна на курсі Node.JS PRO від robot_dreams.

За 22 заняття:
→ опануєте архітектуру бекенду на NestJS
→ попрацюєте з повним циклом продакшену — від коду до деплою
→ навчитеся будувати CI/CD-процеси та автоматизувати деплой через Docker і GitHub Actions
→ опануєте роботу з базами даних та чергами (PostgreSQL, RabbitMQ, Kafka)

Лектор: Кирило Орлов, Senior Software Engineer у LAMPA, який має понад 8 років досвіду в розробці (Frontend, Backend, DevOps-практики й тестування).

Деталі, програма та реєстрація ⬅️

🤫 Чорна п'ятниця весь листопад: розвивайтеся в розробці, AI, OSINT, кібербезпеці, аналітиці й не тільки — з вигодою до -50%.

Сучасний стан AI у фронтенді: з чим ми заходимо у 2026?

Це запис мого виступу з фронтенд-конференції у Чернівцях цієї суботи.

Ми пройшли шлях від табличної верстки в 90-х до React-компонентів, а зараз стоїмо на порозі нової ери — Spec Driven Development.

У відео розбираю:
- Коротка еволюця фронтенду до наших часів.
- Чому LLM краще кодять, ніж пишуть вірші.
- Які є інструменти спеціально заточені на фронтенд.
- Робочий workflow: від Aura.build до Cursor.
- Чому не варто "ваншотити" промтами, а треба писати специфікації.
- Скільки це все коштує.

https://youtu.be/z7fqmpXjVOs

Зимовий DOU

Це мало хто знає, але я був у самій першій команді волонтерів, яких зібрав Макс Іщенко, коли зробив сайт DOU у 2006 році (тоді воно ще називалося developers.org.ua), то можна сказати, що я один з засновників цієї спільноти, бо якби не ми, то навряд би воно стало тим, чим є сьогодні. :)

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

То хочу закинути цілу підбірку важливих заходів від DOU:

1. Зарплатне опитування (думаю саме за рахунок зарплатних опитувань і аналітики по їх результатам DOU став настільки популярним) https://dou.ua/goto/rJks
2. Голосування у рейтингу роботодавців - не полінуйтеся відзначити своє місце роботи, якщо воно у вас є https://dou.ua/lenta/sitenews/ratings-2025/
3. Премія DOU 2025 (мене там теж, до речі, зможете знайти, шкода, поки виграти не виходить, але головне - участь :) https://dou.ua/awards-2026/
4. Черговий збір для Трійки (до речі, люблю збори у DOU, у них є гейміфікаційна складова, і це чудово я вважаю) https://dou.ua/forums/topic/56520/

GenUI

Не знаю, наскільки ці зміни всі усвідомлюють, але людей, що звикли до комунікації через чати складно буде примусити користуватися "класичними сайтами" з меню, фільтрами та 10 рівнями навігації.

Особисто я переконаний, що найближче майбутнє веб-розробки передбачає трансформацію UI/UX у напрямку чатових інтерфейсів і GenUI – коли замість “клікати по сайту” ти просто пишеш, що тобі потрібно, а сайт відповідає не лише текстом, а ще  живими компонентами: карусельками товарів, картками, діаграмами.

Зробив нове відео на цю тему https://youtu.be/7BMPFyZRPmc

Додам ще лінк з доків Vercel AI SDK https://ai-sdk.dev/docs/ai-sdk-ui/generative-user-interfaces

Я дружу з fwdays, робимо з ними цікаві і корисні речі. Хочу поділитися кількома апдейтами.

Deep Dive into LLM APIs
Вже наступного тижня буде воркшоп від мого давнього друга Олександра Краковецького “Deep Dive into LLM APIs”
Планчик воркшопу:
💡 Як працюють сучасні LLM “під капотом”
💡 Які механізми визначають їхню поведінку
💡 Я​​к застосовувати ці знання для створення надійних, керованих і масштабованих рішень
💡 Оцінювання якості та потенціалу моделей на основі метрик.

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

📅 Коли: 15 та 16 грудня, 18:30–21:00 (GMT+2)
📍 Онлайн, Zoom (запис буде доступний)
👉 Реєстрація та деталі: https://bit.ly/4irJPbP

Spec Driven Development запис
Наступне - хто не зміг відвідати мій воркшоп по Spec Driven Development, то доступний його запис ось на цій сторіночці. Там було дві частини - окремо теорія і практика. Поки що це найбільш топовий підхід в розробці з AI агентами, він реально працює і буде лише вдосконалюватися.

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

👉 Доступно тут: https://fwdays.com/event/ai-cursor-video

Rules and commands for Agentic IDE (Cursor, Claude, Copilot)
Ну і нарешті - в середині січня буде мій другий воркшоп з fwdays - тепер по правилам і командам для Agentic IDE. Це база для того щоб нормально ці тули використовувати і там є багато нюансів що треба робити, і чого робити не треба. Ми розберемо всі ключові аспекти в цьому питанні від налаштування системних правил, до створення правил для проєкта на різних його фазах і як направляти агентів правилами чи фіксити їх некоректну поведінку.

Запрошую до реєстрації, ціна ближе до старту зростає, по найнижчий ціні він доступний лише кілька днів.
📅 Коли: 13 та 14 січня, 18:30–21:00 (GMT+2)
📍 Онлайн, Zoom (запис буде доступний)
👉 Реєстрація та деталі: https://fwdays.com/event/rules-ide-workshop

PS. Хто дочитав до цього місця - ловіть купон на знижку: programming_mentor.
Він діє на воркшоп з LLM API та відеозаписи по SDD, мій воркшоп по рулам і командам поки продається по найнижчій ціні early birds, на нього не діє.

Software Engineering 2026

Закінчився 2025, почався 2026. Було б добре підвести підсумки і трохи заглянути в майбутнє.

Без сумніву це був визначний рік по впровадженню AI в Software Engineering. Навряд чи десь є точний показник AI-згенерованого коду по галузі, але по різним оцінкам це вже понад 40%.

Прогноз CEO Anthropic про більш ніж 90% до кінця року не справдився, але я особисто вважаю що це відбудеться у 2026 році, цікаво буде за рік повернутися до цього поста 🙂

Чому я так вважаю? Бо особисто для мене бар’єр у 90%+ подоланий, і зараз рівень AI-генерованого коду впевнено наближається до 100%. Чисто для себе не бачу сенсу в тому щоб навмисно відмовитися від написання коду самому, і якщо потрібно, то звичайно це роблю, але питання в доцільності - з часом її стає все менше.

Причому зміни відбулися буквально протягом кількох останніх місяців - ще в серпні 2025 я робив проєкт, де поряд з генерованим кодом немало писав сам, але вже в грудні - практично мізер самостійно написаного коду, майже 100% AI-генерованого.

Для галузі я бачу це таким чином: у більшості старих проєктів частка “ручного” коду чисто по інерції залишатиметься значною, але нові переважно будуть стартувати з AI-генерованим кодом. Поступово нові проєкти будуть витісняти старі в першу чергу за рахунок швидкості адаптації до вимог ринку.

Відповідним буде попит і на розробників: хто вмітиме писати код лише чи переважно “руками”, незалежно від того яким би він гарним сеньйором не був, буде поступатися тим, хто робить це переважно AI-тулами і володіє відповідними навичками: вміє їх відповідно налаштувати, задати правила, використовувати промпти, приєднати потрібні MCP чи зробити власні, використати skills, оптимізовувати витрати і т.д. і т.п.

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

Ну і звичайно досі досить смішно спостерігати за "борцями зі ШІ", які продовжують щось доводити. Такий нездоровий рівень неприйняття реальності, що не має сенсу витрачати час навіть на суперечки з ними. Мабуть, це вилікується так само, як Мойсей водив свій народ пустелею поки не вимерли ті, хто пам’ятав рабство.

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

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

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

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

[Продовження]

Відповідно і такі підходи як Spec Driven Development будуть розвиватися і використовуватися все активніше, органічно інтегруючись у самі AI IDE по прикладу того як це зробили в Kiro (в Cursor, до речі, віднедавна можна зберігати згенеровані ним плани простою командою, що по суті є одним з рівнів SDD).

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

Ну і про саму професію розробника - звісно вона не зникне, а буде продовжувати трансформуватися. Виграють ті, хто буде мати потрібні знання і навички відповідно до запитів ринку. Має значення технічний стек: JS/TS будуть продовжувати рулити, бо AI з ними справляється чудово, працює код швидко, а ще й під різними платформами. Мови і фреймворки потрібно вивчати, бо для того щоб валідувати код його потрібно також вміти написати самому, зрозуміти чим відрізняється правильний від неправильно, ефективний від неефективного.

Треба вчитися мислити системно, розуміти архітектури і патерни, networking, OS, CI/CD, SQL і багато всього що стосується “традиційного” Software Engineering. Якщо доведеться працювати з фронтендом, то все що стосується сучасного фронтенду з ухилом в React, бо знову ж таки, з ним AI найкраще працює. І це все має підтверджуватися практикою, проєктами, але перш ніж робити своє, потрібно вивчати і розуміти чуже, чому щось є добре і правильно, а чому щось - погано і не правильно. Зробити щось, щоб “просто працювало” мало, потрібно щоб воно було зроблено коректно без дірок у безпеці чи інших критичних вад, цей принцип не змінюється робимо ми з AI чи без.

Зі своєї сторони буду продовжувати працювати в напрямку AI в Software Engineering робити побільше контенту, виступів, воркшопів, курсів і тому подібного. Це мені особисто дуже цікаво - є можливість в прямому етері спостерігати найбільшу трансформацію IT галузі від її появи. Ну і хто ще в цей потяг не застрибнув - сам собі винен :)

Ось це вчорашнє повідомлення від Principal Engineer з Google за добу отримало майже 6 млн переглядів і є найкращою ілюстрацією того, що я написав про Software Engineering 2026.
Вона за годину з Claude Code зробила те, що вони всією командою в Google робили рік :)

Від неї ще є додаткові коментарі що воно не зовсім ідеальне, і коли вона керувала агентом, то враховувала попередній досвід, але все ж.

https://x.com/rakyll/status/2007239758158975130

Історія про те як індуси допомогли українській команді швидко опанувати AI в SDLC

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

Отже, є один проєкт для замовників з США. Приблизно 70% команди, включаючи технічний менеджмент, техліди, сеньйори - це українці, а 30% - індуси, і хоча їх рівень формально мідли, по факту вони більше джуни, просто мають по кілька років досвіду. Так історично склалося.

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

Але у 2025 році, якщо точніше, то кінець весни-початок літа, почалися якісь дивні речі. Індуси почали брати на себе складніші таски, повноцінні бізнес-фічі, і комітити код, який очевидно є AI-генерований. Хоча фічі зазвичай працювали, у наших розробників до того коду були зауваження - то стандарти коду не такі, то залежності додали зайві, то архітектурно не ок і тому подібне, і відправляли назад переробляти. Індусам переробляти не дуже виходило, і хоча фічі наче зроблені, вони на тривалий час підвисали у невизначеному стані.

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

Тривало так певний час, допоки восени американці не покликали український технічний менеджмент на розмову. Розмова виявилася не дуже приємною: американці висунули претензію, що українці блокують роботу індусів, які успішно впроваджують AI в SDLC і навчилися швидко деліверити фічі потрібні для бізнесу, в той час як наші займаються не пойми чим і лише заважають прогресивним інженерам. І якщо вони не навчаться самі використовувати AI і знайдуть спосіб допомагати, а не заважати колегам з Індії, то вони всі швиденько підуть лісом, команда з України буде скорочена, а в Індії розширена, бо у бізнесі важливо деліверити фічі швидко, а не гратися в інженерію. Цікавий поворот, холодний душ на голову нашим розробникам.

На щастя наші все швидко зрозуміли, і почали допомагати індусам виправляти недоліки, і водночас самі почали використовувати AI IDE щоб деліверити фічі швидко. І наче якістю коду жертвувати не довелося, навчилися як рев’ю робити з AI, пулл-ріквести тепер по кілька днів не висять. В результаті всі задоволені - просто фантастичний саксесс кейс, хоча до фейлу було дуже близько. :)

З Днем Програміста!
Класна вікторина від ДОУ.


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

Навіть Торвальдс уже на Темній Стороні.

AI в Software Engineering несеться настільки невгамовно, що навіть Лінус Торвальдс зізнався в тому що з вайбкодингом грішить, сьогодні весь Інтернет у його "зраді".

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

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

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

Хто дочитав до цього місця, є промокод: programming_mentor

Нове відео на каналі:
Оркеструємо агентами замість того щоб писати код вручну
https://youtu.be/q4h1rUlNjsU

Традиційно я в списку премії ДОУ, запрошую підтримати, дедлайн спливає завтра (розділ "Вони - надихають")
https://dou.ua/awards-2026/#nomination5

Shipping at Inference Speed

Можливо ви бачили як зараз несеться OpenClaw (який ще вчора був MoltBot, а взагалі на публіці з’явився з назвою ClawdBot).

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

Йому потрібен доступ до LLM, але не обов’язково палити гроші на платних API, в кого є можливість, то можна підняти якусь фрішну модельку локально. Наприклад, у мене цілком пристойно працює OpenAI OSS-20b на карточці nVidia з 16GB VRAM і це значить, що його робота мені обходиться практично безкоштовно. Залишилося тільки придумати для нього задачі.

Цікаво, що він написаний на TS і після того як з першого разу не запустився, то я просто склонував репозиторій локально на машину, відкрив в курсорі і прямо в ньому попросив допомогти сконфігурувати і запустити, з чим той успішно справився за лічені хвилини.

Але мене найбільше зацікавив автор цього бота - це австрієць Пітер Стейнбергер, за яким я давно слідкую і рівно місяць тому читав його класну статтю “Shipping at Inference Speed” про те як він використовує AI IDE в розробці.

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

Отже стаття тут, must read що називається :)
https://steipete.me/posts/2025/shipping-at-inference-speed

А чи вмієте правильно використовувати LLM?

Я пам'ятаю перші дні використання LLM API, коли все що можна було робити - просто закинути промпт і кілька параметрів типу температури.

Зараз це вже давно не так і є дуже багато нюансів з тим як правильно працювати з API.

У лютому Олександр Краковецький проводить практичний курс по LLM. За Олександра я писав раніше, знаю його давно і він дуже класний фахівець в AI, рекомендую.

Далі деталі курсу, там є цікавий бонус для учасників, я сам його маю в паперовому вигляді :)

📅 Коли? 24&26 лютого
👉 Реєстрація та деталі: https://bit.ly/4a3SRZE
🛠 Теорія і практика: 50/50. Перед стартом учасники отримають підбірку матеріалів.

Ще є промокод на знижку programming_mentor