Сьогодні у нас на каналі новий формат #Smells_Like_Failure.

Правило гри: я викладаю контент, який на перший погляд здається правильним, але в ньому є концептуальна помилка. Коментар з першим правильним описом помилки отримує підписку на JetBrains IDE.

Сьогодні контент — це LinkedIn пост, який я знайшов у себе в стрічці.
—
У нас є переможець!
Рекомендація другові мала бути такою:
Слухай, я бачу за часом відповідей від сервера, що у вас не налаштований кеш для AI запитів. Ви можете витратити багато грошей, якщо будуть надсилатися одні й ті ж запити. Додавання кешу дозволить вам бути більш економними.

📢 ADK Хакатон від Google Cloud

Відкрито реєстрацію на Agent Development Kit Hackathon. Учасники будуть створювати мультиагентні системи для вирішення задач у сферах автоматизації процесів, взаємодії з клієнтами, генерації контенту та ін.

💼 Призовий фонд: $50,000
📅 Подання заявок: з 12 травня по 23 червня 2025 року

🛠 Спробувати ADK можна вже зараз.
ℹ️ Повна інформація про хакатон з’явиться наступного тижня.

Інформацію про хакатон оголосили на Monthly GDE Call.
Я поставив запитання: чи можна буде використовувати Genkit, чи лише ADK?
На жаль, лише ADK. Шкода, адже Genkit має підтримку TypeScript та нім в мене є продакшн-досвід
А ADK вийшов лише місяць тому і поки що доступний тільки для Python.

Я пам’ятаю, що обіцяв зробити огляд Coding with Al конференції – обов’язково виконаю це, щойно отримаю доступ до всіх записів. Декілька виступів я ще не встиг переглянути, тому, як і ви, чекаю відкриття матеріалів.

👀Перше враження
Назва конференції Coding with AI: The End of Software Development as We Know It не зовсім відповідає змісту. 100% доповідей стосувалися власне коду. Натомість теми, без яких ми не уявляємо повного циклу розробки — постановка завдань, збір вимог, найм команди, комунікації, перевірка гіпотез, user experience, аналітика даних — фактично не розкривалися. Тому логічніше було б назвати її The End of Coding as We Know It.

⭐️Speaker, який став відкриттям
Справжнім відкриттям для мене став виступ Гарпера Ріда «My LLM Codegen Workflow at the Moment». Поки немає відео, раджу зазирнути до його блогу – там уже є частина матеріалів із презентації: Harper Reed’s Blog.

⚙️Практичний міні-флоу, який я вже впроваджую:
1. Conversational LLM ставить лише по одному yes/no запитанню за раз.
2. Після серії питань LLM генерує специфікацію у файлі spec.md.
Це допомагає швидко 🚀 уточнювати вимоги й одразу фіксувати їх у структурованому форматі.
—
UPDATE: Прислали запис. Check your email

Ну що, панове backend-розробники, до списку інструментів Node.js/AI/CloudNative я з чистою совістю можу додати TypeSpec.
Минулого тижня Microsoft випустила TypeSpec 1.0 GA

Чому це важливо?
Розширений список 12+3 факторів включає API First Factor.
Саме TypeSpec є тим інструментом, за допомогою якого зручно та швидко дизайнити ваш API.

Тому раджу прочитати анонс і спробувати TypeSpec. Cпочатку на вашому pet проєкті, а потім, хто знає, можете інтегрувати в процеси розробки на комерційному.

Більшість моїх записів присвячені моєму особистому досвіду, заснованому на роботі в стартапах. Проте я цікавлюся трендами, пов'язаними з enterprise, де Angular популярніший за React, а Java більше використовується, ніж Node.js.
Тому сьогодні я хочу поділитися з вами посиланням, яке буде корисним для тих, хто працює саме на enterprise проєктах.

Open Micro Frontend Platform – OpenMFP

Чим цікавий проєкт?
- запущений лише 2 місяці тому
- фінансується Європейським Союзом
- створений за підтримки компанії SAP

А ще це частина Apeiro-Reference-Architecture, де можна прочитати слоган

Unify your services from hardware to software with Kubernetes' declarative power, across any cloud and edge!

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

Сьогодні прийшов імейл, що мою участь у програмі AWS Community Builders продовжено на наступний рік.

Заради цікавості я зайшов подивитися в директорію, скільки у нас білдерів з України. Їх шість. У 2024 та 2025 роках не додалося жодного нового учасника. Це сумно, адже участь у програмі для людини, що створює контент щодо Cloud-ів, одна з найпростіших.
UPDATE: Виявляється, що я не правий. В коментарях знайшовся учасник програми 2025 року. Мабуть, ще не оновили директорію.

Тому пропоную вам написати за цей рік декілька одиниць контенту з AWS/Cloud в зручному для вас форматі. Щоб коли відкриється наступна хвиля заявок у січні 2026 ви мали що подати.

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

Як ефективно зменшити трафік у WebSocket-додатках?

Уявіть собі, що у вашому застосунку кілька разів на секунду мають надходити повідомлення

{ “timestamp”: 1747008028, “price”: 997.538642664439 }

Як тут краще організувати серіалізацію payload-у?

1️⃣ Чому розмір payload має значення?
- Менший пакет → коротший TTFB і менше затримок.
- Економія трафіку = нижчі витрати на інфраструктуру та швидший фронтенд.

2️⃣Порівняння розмірів повідомлень
- JSON-об’єкт {timestamp, price} – 49 byte
- JSON-об’єкт {t, p} – 37 byte
- JSON-кортеж [t,p] – 29 byte
- Protobuf – 15 byte

3️⃣ permessage-deflate (RFC 7692)
- WS мають вбудоване стиснення яке активується у фазі HTTP Upgrade: браузер пропонує, сервер вирішує.
- Алгоритм — DEFLATE (zlib); стиснення «повідомлення-за-повідомленням».
Приклад

new WebSocketServer({
port: 8080,
perMessageDeflate: {
threshold: 1024, // не стискати < 1 KB
clientNoContextTakeover: true, // менше пам’яті
serverNoContextTakeover: true
}
});

4️⃣ Коли вигідно стискати, а коли ні
- Великі JSON (>1 KB) - економія 70-90%, але навантаження на CPU
- Часті дрібні котирування (< 200 😎 - економія ~0%, бо заголовок DEFLATE «з’їдає» вигоду
- Protobuf – простіше вимкнути

👉 Висновки
- Оптимізація payloads нагадує оптимізацію зберігання в MongoDB.
- Перехід з JSON-object → JSON-array → Protobuf вже зменшує пакет у ≈3 р.
- Якщо потрібна читаємість разом з помірним зменшенням трафіку - {t,p} непоганий компроміс.
- Для максимальної продуктивності в стрімах котирувань усе ще лідирує бінарний формат (Protobuf)

Два місяці тому на Soft Skills fwdays’25 Сергій Немчинський зробив доповідь, у якій підкреслив важливість Estimations для бізнесу. Потім ця тема активно обговорювалася в кулуарах і в LinkedIn.

Візія Сергія:

оцінювання ефективніше проводити не в story points, а в “півднях” (half-days). Таски при цьому мають бути нарізані від півдня до максимум двох днів. Якщо більше - дробити. Якщо менше - об’єднувати.

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

Моє бачення питання Estimations:
1️⃣ Самі творці Scrum відмовились від оцінок у їхньому класичному вигляді.

Estimating tasks will slow you down. Don’t do it… No estimation at all will improve team performance over hour estimation.

Jeff Sutherland, співзасновник Scrum і автор Agile Manifesto
2️⃣Відсутність процесу оцінювання ≠ відсутність обговорення задач і усунення невизначеностей.
3️⃣Бізнесу потрібні не оцінки, а предиктабельність (predictability).
Вона досягається тоді, коли задачі дрібні, зрозумілі, і їх регулярно доставляють у продакшн.
Детальніше у книжці NoEstimates.
4️⃣Інженер може дати адекватну оцінку тільки при фіксованому бізнес-скоупі та стабільному технічному стеку. Але заморожувати скоуп і стек - це гальмувати бізнес. І майже ніхто на це не піде.
5️⃣Бізнесу справді потрібні оцінки лише тоді, коли є кілька варіантів реалізації фічі, і вибір залежить від ресурсів. Але практика показує, що краще зробити A/B тест і подивитись на реакцію користувачів, а не гадати.

Ще раз – дрібні задачі, швидкий фідбек від команди та бізнесу ось наш реальний delivery framework.
📌 До речі, практика нарізки бізнес-фіч на дрібні delivery-орієнтовані задачі існує ще з 2016 року
А з появою AI вона почала допомагати не лише бізнесу, але й інженерам, які можуть у AI tools.

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

🧠 VS Code стає відкритим AI-редактором

Цього тижня буде спекотно від новин для розробників: одразу дві топові конференції – Microsoft Build і Google I/O – проходять паралельно. Перша новина від Microsoft – команда VS Code оголосила:

GitHub Copilot Chat стане open source під ліцензією MIT, а ключові AI-фічі поступово інтегрують у ядро редактора.

Моя особиста думка – це продовження курсу на відкритість. Нагадаю ще 3 місяці тому Microsoft анонсувала Language Server Protocol (LSP) для GitHub Copilot, щоб спростити інтеграції в інших IDE та дати розробникам більше прозорості. У довгостроковій перспективі ці обидва кроки надають домінуючу позицію.

Чому це важливо:
- AI вже не плагін – це ядро девелопменту.
- VS Code офіційно трансформується в AI-платформу з відкритим кодом, і Microsoft запрошує спільноту долучатися
- iteration plan та FAQ.


Що далі:
– Open source Copilot Chat
– Інтеграція AI-компонентів у core VS Code
– Відкриття інфраструктури для prompt-тестування

І на завершення, вірусне зображення OpenAl acquires Windsurf

Як AI змінює інтернет?

Десятиліттями інтернет працював за простою моделлю: користувач → пошуковик → сайт. Люди отримували відповіді, сайти – трафік, а творці контенту мали стимул створювати більше. Саме так і працював вільний веб.

Але генеративний AI (ChatGPT, Gemini, Claude) змінює гру: відповіді з’являються без переходів на сайти. Контент поглинається, але нічого не повертається авторам – ні переглядів, ні грошей.

Парадокс:
✍️ Ручне створення якісного контенту – дороге і повільне
🤖 Генеровання AI-контент – швидке і дешеве, але часто поверхневе.
🧠 І при цьому, AI вчиться та генерує відповіді на основі саме ручного контенту, який створили люди – навіть якщо моделі були дистильовані чи донавчані на проміжних репрезентаціях, їхня база все одно – ручна людська робота.

Без нових джерел знань AI почне "висихати". Ми вже бачимо перші ознаки цього – контент повторюється, втрачається глибина, а сенс розчиняється.

🎯 Що робити?
Розробники краще розуміють технічні ризики, ніж бізнес. І саме ми маємо запропонувати рішення, як захистити контент у нову епоху AI:
1️⃣ Додавай структуровані дані
Використовуй schema.org, OpenGraph, JSON-LD – це робить автора видимим для пошуковиків і AI.
2️⃣ Контролюй доступ до індексації
Налаштовуй robots.txt, meta noindex, data-nosnippet – це пряме заява, що ми не хочемо, щоб нас парсили.
3️⃣ Вшивай авторство у контент
Водяні знаки, унікальні посилання, сигнатури – усе це зберігає атрибуцію навіть у відповідях AI.
4️⃣ Захищай API/site
Додавай rate limiting, ключі доступу й умови використання. Підготовка до монетизації – вже зараз.

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

Учора Google анонсував AI coding agent Jules. Реєстрація на Beta уже відкрита. Під капотом використовують Gemini.2.5. Я поки що чекаю доступу.
UPDATE: Е-мейлу не було, але через 3 години доступ вже з'явився, тому замінив скріншот.

Для реального тестування, базових лімітів до 5 задач на день, ймовірно, мені не вистачить. Тому потрібно буде запитувати їх підвищення.

Ще вчора OpenAI також надав доступ до Codex у Teams.
Тому, можливо, я їх буду тестувати разом на одному і тому ж обсязі задач.

Чому це важливо? Тому що підтримка TypeScript/Node.js часто з'являється першою у AI Coding Agents.

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

🟡 Непопулярна думка:
- Досвідчений джун - це не сеньор.
- Досвідчений сеньор - це не архітектор.
- Досвідчений архітектор/техлід - це не СТО.

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

🧠 Ключова думка:
Сеньори з’являються не з джунів, а з недосвідчених сеньорів.
СТО з’являються не з архітекторів, а з недосвідчених СТО.

Кілька свіжих прикладів
1️⃣ Node.js девелопер, який 5 місяців шукає роботу сеньора. Я звів його з рекрутером, він провалив навіть базову комунікацію.
Його аргумент: «Ну, для HR комунікація - це головне, а для мене - допоміжне». Але це і є проблема: сеньор - це передусім про ефективну командну взаємодію.
2️⃣ Колега, що скаржиться, як його “недооцінили” на system design інтерв’ю. Йому пощастило, йому дістався завдання зробити систему, яку він уже робив для мільйонів користувачів. Але… забув зібрати вимоги, не продав ідею, не доніс цінність.
Архітектор – це не про те, що ти вже колись робив. Це про те, як ти комунікуєш свою експертизу тут і зараз. Інтерв’ю – це теж робоча ситуація.

AI не забирає роботу. Він просто більше не дає ховатися за «ще рано», «я не впевнений», «мені не дали шанс».
У сильних – це інструмент, а у інфантильних – конкуренція.

У коментарях запитали:

нащо потрібні 10 сіньйорів якщо ту саму работу можуть з ші зробити 3 от нащо хтось може пояснити? =)

🎓Для тих, хто не вчив економіку: що таке парадокс Джевонса?
Коли з’являється технологія, яка робить щось ефективніше (дешевше, швидше, з меншими затратами) – попит на цю річ… зростає, а не падає.
Парове вугілля стало ефективнішим – його почали використовувати більше, не менше.
AI зменшує вартість коду – значить, будуть хотіти більше коду, а не менше.

👉 То чому ж потрібні 10 сеньйорів?
AI не скорочує попит на інженерів – він відкриває нові юзкейси, які раніше були занадто дорогими або складними.
Бо змінюєтся сам підхід до розробки.
Раніше бізнес купував готовий SaaS і підлаштовував під нього процеси.
Тепер він може найняти одного програміста з ChatGPT – і отримати свій внутрішній продукт, який автоматизує саме його бізнес-логіку.
Не підлаштовуватись під софт, а писати софт під себе.

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

🧠 Ще раз: AI не прибирає людей – він прибирає лінивих та інфантильних.
Сеньйори (не за вислугою років, а за майндсетом) залишаться, бо саме їх мозок і judgment потрібні більше, ніж коли-небудь.

У коментарях запитали:

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

Зверніть увагу, що архітекторів буває багато різних типів
- архітектор, зосереджений на пресейл-активностях, повинен також мати навички в продажах.
- архітектор, який виконує функції R&D-інженера, буде писати багато нового/складного коду.
- архітектор, що виконує роль техліда, відповідатиме за внутрішній framework та code review

🎓 Домовимось про терміни.
Для мене позиція архітектора - це переклад продуктової візії в технічне бачення. Це саме те, від чого я кайфую.
Такому архітектору потрібно cбирати вимоги, знаходити сліпі зони або пропонувати щось самому.

Ось топ-5 компетенцій для такого архітектора:
1️⃣ Product mind set – українською мовою дуже класно @product_borsch
2️⃣ Технологічний стек. Звичайно, у вас буде улюблений toolset, but don’t be merried with that. Тому потрібно вміти читати код на кількох мовах. Критерієм "розбираюсь/не розбираюсь" є здатність написати Architecture Decion Record щодо вибору технічного стека для нової функції. Використання GPT-чату або інших експертів - це нормально
3️⃣ DevOps/CloudNative – бери одну хмару і розбирайся в ній досконало. Якщо необхідно перейти на іншу, це не проблема. Сертифікати допомагають у "Зробив/Не зробив".
4️⃣ Діаграми та архітектурні шаблони. Основні артефакти роботи архітектора, як й Architecture Decision Record.
5️⃣ Останнє у списку, але найважливіше. Вміння переключатися між рівнями. Приклад https://fwdays.com/en/event/architecture-fwdays-2023/review/exploring-mach-principles

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

Колеги, хочу попросити вас заповнити Node.js Next 10 Survey, яке регулярно проводить Linux Foundation.
На основі цих даних команда Node.js Core визначає пріоритети розвитку нашого основного інструменту.
По суті, вони намагаються сформувати бачення розвитку Node.js на найближчі 10 років.
Подивитися результати минулорічних опитувань можна в цьому репозиторії

З коментарів:

приємний сюрприз що sqlite розглядається як частина стд бібліотеки

Мій коментар:

Ми можемо спостерігати конкуренцію між JS runtime'ами: NodeJS vs Bun vs. Dino.
Це добре, бо саме через цю конкуренцію ми й надалі будемо спостерігати додавання пакетів у Node.js core, як це було з undici, SQLite, env-file.
Наприклад, Bun надає SQL/Redis/S3/etc, а Deno – OpenTelemetry. Тому скоро ми можемо побачимо деякі з цих залежностей у Node.js.

Якщо подивитися на те, що виходить у Bun/Deno, це дуже нагадує Ruby on Rails, коли runtime та framework це одне й теж. Node.js також рухається в цьому напрямку, але значно повільніше, забираючи з того, що вже є. Мені здається, що це правильний напрямок, тому що це покращується DevEx.

Поділюсь своїм баченням поточних реалій ринку.

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

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

⚠️ Ця ситуація характерна як для українського, так і для міжнародного ринку.

Що з цим доводиться робити?
У межах консалтингу я додаю тестове завдання до технічної співбесіди. Рекрутер попереджає, що буде розгорнутий фідбек за результатами. Нижче – статистика за 2025 рік за двома вакансіями: Senior FullStack і Senior Node.js Developer.

- Взяли тестове завдання – 17 кандидатів (із них задали уточнювальні питання – 3)
- Прислали виконане завдання – 11
- Завдання виконано на рівні Senior – 4
- Завдання виконано на рівні Middle – 2
- Зроблено оферів за підсумками співбесід – 1

Основні проблеми в тестових:
👎Додаток не запускається або не збирається.
Приклад: конфлікти версій бібліотек.
👎Обрано невдалий архітектурний підхід або технологічний стек.
Приклад: реалізація real-time (WS/SSE) у NestJS без використання RxJS.
👎Відсутні важливі фічі.
Приклад: у FullStack-завданні була явна задача на sharing у соцмережах, але її не реалізували бо use client
👎Ігнорування базових best practices.
Приклад: захардкожені змінні замість використання env vars, потенційні security-уразливості.

Основні проблеми під час обговорення тестового на технічній співбесіді:
🤦‍♂️Кандидат не може пояснити прийняті рішення або власний код.
🤦‍♂️Кандидат не здатен внести правки у свій код.
Приклад: “Давайте виправимо цей незначний баг” – і починається паніка.

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