Ви, скоріше за все, знаєте Лірана Таля за його доповідями про Node.js та безпеку. Він є автором:
🔗 npm Security Cheat Sheet
🔗 Node.js Docker Security Cheat Sheet
🔗 Node.js CLI Apps Best Practices

У нього також є email-розсилка Node.js Security Newsletter з якісним контентом. На цю ж тему він написав кілька книжок - їх можна як знайти на торентах, так і придбати, щоб підтримати автора.

Ще я стежу за ним у медіа, і як багато інших авторів у світі Node.js, він активно працює з AI.
Із останнього - він виклав два цікавих репозиторії:
- awesome-mp-best-practices — найкращі практики для MCP-серверів і клієнтів
- ls-mcp — npm-пакет CLI для перегляду конфігурацій MCP-серверів у системі

5 липня відбудеться офлайн-конференція 🤖 AI-конференція Fwdays+DevRain.

Усі доповіді проходитимуть офлайн, трансляція буде доступна онлайн. Конференція збере найкращих українських спікерами з Microsoft, Google, Reface, MacPaw, DevRain та інших. Так серед спікерів - лише ті, хто фізично перебуває в Україні.

🎯 Теми: GenAI, LLMs, безпека, ML в продуктах, практичні кейси.

Використайте промокод Recipes10 та отримайте знижку 10%, деталі за посиланням 👉 https://bit.ly/45fvOJA

Я подивлюся трансляцію або запис. Цікаво, яка частина спікерів буде використовувати napkin.ai для створення зображень для слайдів.

На проєкті, де я надаю консалтинг, зупинилась розробка. AI Agent-и та розробники не можуть нічого робити бо CI/CD пайплайни зламані.
Можна, звісно, звинувачувати NPM - у них не працює встановлення пакетів (помилки 502/504), але справжня причина в іншому - у GitHub Actions не налаштовано кешування ні для NPM, ні для побудови Docker-образів.
Так робити не можна. Швидкість та стабільність ваших пайплайнів забезпечується саме кешуванням залежностей.
——
Ще я спостерігаю проблеми в інфраструктурі Google - Google Meet, Firebase Auth - хтозна, чи це збіг.

Сьогодні поговоримо про Terraform і на кого підписатися, щоб бути в курсі його екосистеми.
⠀
🤔Почну з головного питання – навіщо тобі, дорогий читачу, Terraform?
Щоб бути інженером, а не просто розробником.
Розробники вміють тільки писати код (на одній мові / фреймворку), тому їх легко замінює AI.
А от інженер створює продукти, відповідає за їхню роботу аж до продакшену і розуміє DevOps практики.
Terraform – це стандарт де-факто серед IaC (Infrastructure as a Code), тому знати його – мастхев.
⠀
🎓Власне, як його вчити? Перевірено на особистому досвіді.

📗Теоретична база:
1. Готуємося до сертифікації Terraform Associate
- learning path by HashiCorp
- відео by FreeCodeCamp
2. Опціонально здаємо іспит за $70 (робочих знижок чи ваучерів я не знайшов)
3. Читаємо Terraform Best Practices
⠀
🛠 Практика:
1. Паралельно з теорією пишемо інфру для свого комерційного або pet-проєкту в тому хмарному провайдері, що тобі зручний.
2. Поступово додаємо інструменти з Terraform-екосистеми:
- tfenv
- tflint
- tfupdate
- checkov
- pre-commit-terraform
⠀
📬 Як бути в курсі?
Книга і pre-commit-terraform написані моїм улюбленим AWS Hero – Антоном Бабенко.
Він регулярно стрімить на своєму YouTube-каналі та веде Terraform Weekly.
Я читаю його дайджести, а ще реліз-ноути Terraform та провайдерів, які використовую.
⠀
Наприкінці посилання на останнє відео Антона з AWS Community Day Armenia.

Щоб закрити тему Infrastructure as Code, публічно прокоментую альтернативні підходи:
- OpenTofu (форк Terraform) зроблений компаніями-конкурентами, щоб і далі заробляти на Terraform після зміни ліцензії HashiCorp у версії 1.6. Жодна з них не інвестує на рівні HashiCorp, тому продукт і екосистема однозначно програють Terraform.
- Pulumi – IaC, який просувається за рахунок можливості описувати інфру на вашій улюбленій мові програмування (не треба вчити ще одну мову, як для Terraform). Але з розквітом AI-enabled development ця перевага для мене повністю втратила сенс. Якщо хочеться погратися з таким підходом – подивіться CDK for Terraform: робить те саме, але залишає вас у найпопулярнішій екосистемі. Також не рекомендую через дорогу бізнес-модель – платити $0.37 за ресурс у кожному стеку / оточенні – це дорого для IaC.
- Vendor-specific IaC – CloudFormation від AWS, Azure Resource Manager, Cloud Deployment Manager від Google Cloud. Не рекомендую, бо жорстко прив’язують вас до екосистеми одного вендора.
- IaC від frontend-інженерів – alchemy.run, sst.dev та інші. Категорію назвав так, бо вона нагадує: «я не розібрався в наявних фреймворках – тому зробив свій». Виглядають цікаво, і можна отримати користь, якщо розібратись, як вони працюють. Але – низький adoption, незрозуміло, хто за ними стоїть і скільки вони протримаються на ринку – тому не можна використовувати для комерційних проєктів.
- Infrastructure from Code (IfC) – почитати можна тут. Сайт зроблений командою ampt. Змішує код і опис інфраструктури. Підхід не новий – так працює, наприклад, Firebase Functions. Але на практиці створює більше проблем, ніж переваг, і замикає вас у фреймворк, нав’язаний тулом.

Завершу фразою зі списку «Ось що я хотів би знати як професіонал, коли мені було 30»:

Ми обираємо не просто інструмент або фреймворк – ми обираємо цілу екосистему і спільноту.

Так от, мій вибір – Terraform, бо в нього найбільш розвинена екосистема (є, по суті, будь-який провайдер і багато крутих утиліт) і класне ком’юніті.

lovable.dev – один із веб-інструментів для вайбкодингу безкоштовний у безлімітному режимі на цих вихідних.

Чудова нагода завайбкодити щось круте!

Як розробник підходить до відладки?

Junior – додає console.log() і шукає помилку у виводі.
Middle – користується дебагером і покроково аналізує код.
Senior – пише тест, що відтворює баг, і виправляє проблему.

Трохи контенту
- Подкаст з Сергій Бабіч Хто такий Senior Software Developer?
- Стаття на DOU Коли ШІ погано виконує роботу бекендерів і чи замінить він джуніорів

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

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

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

Об GPT‑5

Тепер GPT‑5 працює всередині ChatGPT як єдина система без потреби вручну обирати «режим мислення» — маршрутизатор автоматично активує просунуту версію моделі для складних запитів або якщо користувач прямо просить «подумати». Альтман назвав попередній інтерфейс вибору моделей «дуже заплутаним».

Як я розумію у перекладі з маркетингової мови:
Користувачі запускають дорогі моделі навіть для простих запитів, які легко обробляють і попередні версії. На цьому ми втрачаемо гроші, тому тепер ми самі вирішуватимемо, яку модель використовувати.

UX in X Developer Portal

Не любите не вмієте верстати? Я теж.
Але іноді доводиться правити Tailwind.
У цьому більше виручає не AI, а розширення для Chrome 👉 gimli.app/tailwind

Відрізнити бота, користувача через LLM і людину, що сама натискала кнопки, стає дедалі складніше.
А це означає, що бізнес усе частіше просто не буде робити різниці між ними.

У якості підтвердження своїх спостережень пошлюся на пару новин:

Sam Altman, CEO OpenAI, написав:

i never took the dead internet theory that seriously but it seems like there are really a lot of LLM-run twitter accounts now

У той же час розробники Chrome та Edge створюють WebMCP, щоб перенести Model Context Protocol (MCP) з backend на frontend:

Web pages that use WebMCP can be thought of as Model Context Protocol (MCP) servers that implement tools in client-side script instead of on the backend

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

Ось така розмова вийшла з колегою-архітектором.

привіт Нікіта

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

Можливо знаєшь якість інструменти? можливо якийсь npm пактет котрий міг би давати змогу вести зручну документацію для кожного репозиторія?у клієнта Azure інфраструктура

привіт
1. як я тебе зрозумів
- є система (або група застосунків), код якої зберігається як polyrepo
- є технічна документація, що зберігається в окремому репозиторії
2. як я зрозумів проблему — неактуальність документації. Вона частково спричинена тим, що зміни в репозиторіях app1/appN із кодом не завжди супроводжуються змінами в репозиторії з документацією docs
3. що я припускаю за контекстом
- використовується GitHub Actions
- проблему не вдається вирішити використовуючи тількі інженерну дисципліну
4. що б я зробив
- продовжив би використовувати один репозиторій для документації як джерело правди
- додав би в кожен репозиторій папку docs
- створив би reusable GitHub Action, який копіює зміни з appN/docs у docs/appN
у результаті розробники відповідають за документацію на рівні репозиторію, а архітектори — на рівні docs
5. опційно
- для людей із репозиторію docs зробити автопублікацію сайту з документацією (є багато готових рішень для перетворення markdown → HTML)
- вибрати й задокументувати технічний стек у репозиторії docs, додати скрипти для перевірки відповідності у всіх репозиторіях (наприклад, версія TypeScript/Eslint/etc)
- реалізувати підхід для генерації специфікацій із коду (Swagger чи його аналоги) і збірку зі всіх репозиторіїв
- для AI coding agents — створити власний MCP сервер. Спочатку з документацією, пізніше з метриками з інфраструктури й даними з застосунків

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

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

CREATE TABLE "<table_name>_backup_<migration_timestamp>" AS TABLE "<table_name>"

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

Self-code review – це практика, коли розробник самостійно аналізує свій код перед тим, як відправити його на зовнішній рев’ю або змерджити у main branch. Її мета – знайти помилки, підвищити якість, узгодженість і зрозумілість коду ще до командного перегляду.

У 2025 році я вважаю використання AI для аналізу власного коду невід’ємною частиною процесу self-code review. Зазвичай я запускаю кілька циклів AI code review, перш ніж позначити pull request як готовий.

Що я для цього використовував
🤖 AI Self-Review (JetBrains)
🤖 Codex (OpenAI)
🤖 GitHub Copilot

Для мене GitHub Copilot показав найвищу якість аналізу та швидкість роботи. Навіть без додаткової кастомізації (яку, утім, рекомендую налаштувати), Copilot ефективно підсвічує потенційні проблеми, пропонує релевантні фікси й адаптується до стилю коду. Його можна легко перезапускати кілька разів.

👉 Рекомендація: тримайте Copilot увімкненим за замовчуванням для всіх pull request’ів – це забезпечує відчутний приріст якості ще до командного рев’ю.

Деякі спостереження
1️⃣ AI перевершує людину у виявленні очевидних помилок.Наприклад, сьогодні AI помітив, що я переплутав min і max у розрахунку high/low для свічкових графіків – банальна, але критична помилка, яку ШІ знаходить миттєво.
2️⃣ AI поступається у забезпеченні єдиної стилістики та узгодженості коду на рівні всієї системи.Він не розуміє архітектурного контексту, внутрішніх домовленостей чи специфіки доменної логіки. Тут досвід і відчуття цілісності системи залишаються прерогативою людини.
3️⃣ AI майже не здатен виявити пропущене у pull request. Нажаль людина теж.

TL;DR; Human in the Loop – найкраща стратегія використання AI.

Хочу показати вам різницю між продуктовими та платформенними інженерами.

Учора в розсилці ADVENTURES IN NODELAND, яку веде Matteo Collina, вийшла чудова стаття — Noop Functions vs Optional Chaining: A Performance Deep Dive. У ній автор детально пояснює, чому Noop function працює швидше за Optional chaining.

// Підхід 1: Noop function
function noop() {}
function testNoop() {
noop();
}

// Підхід 2: Optional chaining
const a = {}
function testOptionalChaining() {
a.b?.fn?.();
}

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

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

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