У розробці ПЗ з AI вже видно розкол. Перші вкладають потужності AI у швидкість, інші у якість.

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

Чтобы признать, что ты не можешь решить задачу, нужно уже обладать уровнем, достаточным для ее решения.

Если уровня понимания сложности не хватает, то задача обычно решается криво, но человеку кажется, что все хорошо. Если понимание сложности задачи есть, то чаще всего проблема не в нехватке знаний или опыта. Обычно не хватает другого: времени, внимания, сосредоточенности, упорства, чтобы дойти до сути и не свернуть раньше времени, учловий работы, чтобы не дергали (ну сам себе не создал таких условий).

Так что, берите тех людей, которые говорят, что "не могут" и помогайте, их предел обычно ближе к реальности. А вот уверенность тех, кто сразу заявляет, что все элементарно, означает, что они не видят глубины.

Axios Supply Chain Attack

хто там не слухавсі? я вже 6-7 років кажу, що потрібно викидати цю бяку, швидко переходимо на fetch api, undici, node.js built-in api

https://thehackernews.com/2026/03/axios-supply-chain-attack-pushes-cross.html

Илья, ну чем сейчас людям выделиться? На фундаментальные знания нет времени, а фреймворки не позволяют выделиться, шаблонный код неплохо пишет AI. У меня никогда не стояла задача выделяться, да я никогда и не заходил в проекты через собеседования, вакансии, через обычный процесс. Основным стимулом для изучения нового у меня был интерес, просто хотелось в чем-то разобраться и лучше всего прямо в процессе делать это руками.

Я знаю, как работает найм только потому, что сам набирал в команды и собеседовал. Наблюдал, как построен найм вокруг, и это всегда был какой-то треш. Теперь процесс найма стал войной нейро-слоп-резюме с нейро-фильтрами. Никаких шансов выделиться ни через знания, ни через умения нет. Процесс стал рандомным, и теперь кажется, что раньше он был не такой уж и трешевый.

Тут про AI для звичайних людей, розважально-просвітницький ефір із шутейками

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

Наразі немає проблеми у доступі до знань, всього повно, немає часу на це.

Курси, ментори, мітапи, конференції – не змінюють поведінку без впровадження у реальну роботу. Курси не встигають розробляти, AI занадто швидко жене всіх уперед, на конференціях розповідають те саме, що й 5-10 років тому це безглуздо.

Статті та книги вже безповоротно відстали. Вчора бачив у книгарні: HTML, CSS (книга по верстці, буває ж…), Java, Python, ASP .NET (він що, живий ще?). Гаразд, є гарні й товсті книжки, у мене на полиці стоїть Дональд Кнут, SICP, весь Робер Мартін та Ерік Еванс… ні, не хочете почитати Фаулера чи Клепмана?

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

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

Хто вибрав “Читаю та вивчаю чужі вихідники” - я вам не вірю, ви не читаєте навіть те, що вам генерує AI, і що пишуть колеги у проекті, а тут чужі похідні коди, так-так-так…

У чому полягає ефективність інженера у 2026? Якщо пам'ятати API та патерни на пам'ять це точно не головне, якщо інструменти та AI доступні усім, знання доступні як ніколи, але на їх опанування немає ані часу ані уваги.

Тоді що головне?

Сила інженера сьогодні в іншому. У здатності формувати світогляд і бачення, задавати напрямок для своїх думок та для того ж AI.

У мене спитали після лекції "Де ви берете стільки різноманітних слів та ідей. Бо от я що не напишу - все контролер виходить. А у вас все різне."

У чому секрет? Об'ємне бачення формується зі світогляду, а воно напрацьовується роками на практичних задачах. Наприклад:
- У мене є бекграунд кібернетики та обробки сигналів, системного програмування, наукової діяльності, у кожного було своє оточення та точка старту, у когось геймдев, у когось сайти чи системи звітності, зверніться до цього першого досвіду, де сформувалися думки,
- Ще є родина, що на вас вплинула, от у мене родина архітекторів та художників сформувала спрямованість на естетичні рішення, а перший наставник по програмуванню заклав цікавість до техніки та до педагогіки, і як це поєднати
- Пригадайте, що ви можете взяти від старших колег, я у перші 10 років набирався від колег не стільки як програмувати, (ні хто мій код не дивився, до речі), а навчився я того, як працювати із людьми, з замовниками, як формувати задачу, як обговорювати шляхи вирішення...
- У великому державному ІТ я дізнався, як працювати з ризиками, як бачити ціну помилки, знаходити вузькі місця (не не у технологіях, а у людській взаємодії) і як посилювати людей, як відвадити їх від хибних думок так, щоб вони самі побачили проблему, а не наказовим чином їм щось прилетіло (змушені працюють неефективно).
- AI зараз генерує тонни коду, і що, хто це буде читати, хто за це буде відповідати чи орієнтуватися у цьому? Тримати AI у руслі вашої думки, а не нести вас невідомо куди - ось що важливо зараз. AI має знімати рутину, а не мислення з вас.
- Раніше інженерне мислення очікувалось від синьорів, тепер воно має бути у всіх інженерів. Бо коли код, знання і доступ до інструментів стали дешевшими, дорожчає тільки ясність думок та якість рішень.

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

Вот собрал тут что важно по хардскилам, вместо ваших алгоритмов, литкода, высоконагруженных кабанчиков и карго-культа микрооптимизации:
- Data structures (just how to use)
- Type systems: nominal, structural, variance...
- Modularity system (in your language)
- Polymorphism (Ad-hoc, Subtype, Parametric, etc...)
- Structural composition, aggregation, delegation
- Functional composition, pure functions
- Abstraction layers separation
- Dispatch and Dynamic dispatch
- Referential transparency
- Law of Demeter
- Referential transparency
- Abstract data types (ADT)
- Hidden and explicit state
- Lazy evaluation
- Declarative vs imperative style
- Recursion versus loops
- Generics (generic programming)
- Separation of concerns
- Isolation, interfaces, architectural boundaries
- Dependency injection and Inversion of control
- Coupling and cohesion
- Mutable vs immutable data
- Idempotent operations
- Naming conventions
- Error handling
- Refactoring, code review process
- Tests (unittesting, coverage, end-to-end...)
- Multiparadigm programming
- Metaprogramming (codegeneration and dynamic)
- Platform-agnostic, framework-agnostic approach
- Domain-Specific Language (DSL), Interpreter, AST
- Contract programming
- Concurrency and Asynchronous programming
- Separation of system and applied code
- Language and semantics
- AI-assisted engineering
Но все это тоже должно занимать в голове не более 30% от развития инженера, as of 2026. Про 70% напишу еще чуть позже

Суббота 18 апреля в 18-00 (Time zone: UTC +3 Eastern European Summer Time)

https://www.youtube.com/live/mSVCQ0VzIAo

Нагадую: сьогодні о 18-00 стрім, де ми розберемо, як у 2026 залишатися актуальним та розвиватися професійно незважаючі на ШІ, звільнення у ІТ, економічну кризу, тотальне прискорення та нестабільність в усьому світі. Що робити звичайному інженеру, бо просто бути вже замало, як це було на зростаючому ринку. Просто фронтенд чи просто бекенд це все замало, навыть фулстек но може собі дозволити розслабитися.
https://www.youtube.com/live/mSVCQ0VzIAo

картинка - по мотивам стрима

А наше решение тут - https://tg.pulse.is/next_tick_bot?start=69ce57941f15eb55e90ea47a&source_channel=timur_tg_metarhia

Дякую ШІ, що тепер є кому читати мої Design docs, ADR, RFC та інші md файли, концептуальний код, складні ТЗ та приклади коду, такого вдячного читача складно було уявити.

З усіх моїх курсів по петтернам, по Node.js, з асинхронного програмування, з архітектури, люди навчилися не патернам і не ноді, а натренувалися по декомпозиції, рефакторингу, керувати розподілом відповідальності, зачепленням, структурною композицією та делегуванням, станом, ізоляцією, тим, що взагалі массово люди погано вміють і погано ставлять задачі AI на це. Самі ж патерни ми використовуємо щодня ну 5-10 може, але не 23 як у GoF і не сотню, якщо рахувати разом з архітектурними та іншими non-GoF, інші потрібні раз на 2 роки або взагалі раз у житті. Цінність цих курсів не в заучуванні патернів та api ноди. Це лише привід для інженерного мислення. Тут новий формат і ми вже скоро закриваємо набір: https://tg.pulse.is/next_tick_bot?start=69ce57941f15eb55e90ea47a&source_channel=timur_tg_metarhia

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

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

https://youtu.be/DV6AYHrtBeU