Трохи моїх думок про вектор руху ІТ ринку
Це стосується тільки інженерних напрямків, бо в інших я некомпетентний:
- T-Shaped Skills залишається найбільш стабільним вектором розвитку
- Full-stack більше не про frontend/backend. Все частіше потрібна людина, яка добре розбирається в backend/infrastructure, а навички писати frontend все частіше відходять на другий план (окрім випадків де він реально складний)
- Все частіше потрібне розуміння того, як інтегрувати АІ в продукти. Сюди можна включити розуміння болячок і оптимізації АІ
- Вимоги по hard skills ростуть і таке відчуття, що ІТ знову стає доступним тільки для тих, кому подобається вся ця технологічна дрочь
- Важливість soft skills виходить на новий рівень. З появою АІ, роль інженера змістилась в бік бізнесу і тепер все частіше потрібно трансформувати бізнес-вимоги в технічні задачі для агентів
Підписуйся на мої блоги:
Telegram — t.me/devshive
YouTube — www.youtube.com/@devs_hive_ua
17 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарівконтрадікшен детектдед
Та чому, зараз без сильних хардів з вами ніхто говорити не буде. А як харди норм, будуть дивитись софти і вміння вирішувати проблеми
два сети які слабо перетинаються, хіба вийде який Ілон, але хто ж його найме
Та ну, вони дуже повʼязані між собою. Яка різниця на скільки спеціаліст хороший технарь, якщо він не зможе вникнути в бізнес і прийняти рішення, яке найбільш підходить в конкретному випадку
це не про війти в бізнес (буде частка від бізнесу?), в тебе трохи не те розуміння що таке тяжкі і легкі навички
та ні, якраз розуміння правильне. Тут нема що гадати, можна в чата жпт спитати про харди і софти, а щодо того що потрібно компаніям, можете зайти на умовний YCombinator i проаналізувати вакансії
і що це дасть? візьмуть за СТО приймати рішення? чи як?
Будете розуміти, куди рухається ринок і що робити)
dou.ua/...rums/topic/61397/#3112912
рухається в сторону ппц,
загорнутись в простирадло і повзти в сторону найближчко цвинтара © (тм)
Харди питають тільки на співбесіді і то точно таке враження що тебе наймають як мінімум у гугл. А потім переважно треба перекладати незрозумілі самому замовнику побажання у якусь спеку, по якій ШІ напише код на якій завгодно мові а MR у 90% випадків апрувнуть недивлячись, бо його вже дивився інший ШІ
Разделение труда и специализация появилась не на пустом месте. Каких-то 15 лет назад один человек мог и витую пару в офисе прокладывать, и сотню пользовательских машин админить, и сайт на джейквери и пхп написать, и сервак с базой настроить. Но потом технологии усложнились и появились отдельно девопсы, фронтендщики, бекендщики и еще куча других специализаций. И даже в том же вебе реально щарящих фулстеков были единицы, а основная часть — это либо бекендщик с азами фронтенда, либо наоборот.
Никто и раньше не мешал продукт овнерам и бизнес аналитикам учить джаваскрипт и пайтон, а девам — разбираться в бизнесе. Только вот почти никто этого не делал. И не потому, что не было магичесских ЛЛМ, а потому что время и энергия человека ограничены. И в этом плане ЛЛМ ничего особо не изменили: они не сделают из технаря бизнесмена, и они не сделают из бизнесмена технаря.
Конечно быстро набросать прототичик или сайт визитку ЛЛМ помогут, но это не является какой-то революцией. И раньше на апворке сидела пачка индусов, которая за 200 долларов сделала бы тебе абсолютно то же самое и с тем же качеством, что и современные ЛЛМ. Реальная техническая сложность никуда не делась ни в бекенде, ни во фронтенде. Но вдобавок появился еще один слой сложности — интеграция и оптимизация ЛЛМ и агентов на их основе. И я уверен, что как раньше бизнес аналитики и продукт овнеры даже не пытались лезть в фронтенд и бекенд, так и сейчас они даже не будут пытаться лезть в агентик воркфловы.
Ну я ж якраз це все і написав в дописі. T-Shaped Skills якраз таки означають глибоку експертність в одному напрямку, але через доступність знань і той же АІ бекендщик може розібратись і в суміжних областях для того, щоб краще розуміти як працює продукт і система.
Згоден по всім пунктам. Цікаво, що ще задовго до АІ, десь роках у2014-2019 вже був певний відсоток технічних спеціалістів, які казали всім іншим — інженер має не тільки думати про інженерні задачі, а ще й розуміти бізнес. На що десь 80-90% інженерів тоді казали: «Та не наша то справа! Є бізнес-аналітики, проджект менеджери, продукт оунери — хай вони в цьому всьому розбираються, а наша задача лише про технології думати, а не про бізнес». І от зараз світ змінився так, що якраз таки саме інженерам треба активно починати думати не лише про технічну частину проекту, а й про бізнесову, якщо у найближчі 5-10+ років вони хочуть залишатися бажаними спеціалістами на ринку.
З іншої сторони, вірно й зворотнє — якщо ринок буде насичений сильними технічними спеціалістами, які ще й бізнес розуміють і можуть одночасно і з клієнтом мовою бізнесу розмовляти, і з АІ чітко обговорювати, планувати та імплементувати технічні аспекти проекту — то виходить значно падає цінність не лише чистих інженерів, а й чистих бізнес-аналітиків і т.п. спеціалістів, які не будуть вміти робити технічні штуки за допомогою АІ. Тобто виглядає так, що адаптуватися потрібно всім — технічним спеціалістам розбиратися у бізнесі, а тим хто розбирається у бізнесі — розбиратися в інженерних речах.
Мені здається зараз буде дуууже багато змін і класичні спеціальності будуть трансформусатись в нові. Наприклад Product Engineer, якось теж писав про цю спеціальність, Forward Deployed Engineer, а в галерах подешевше буде щось по типу AI Enabled Full-Stack Engineer
Коротше, хз як воно буде, але виглядає так, що ті хто з досвідом і готові вчитись отримають буст, а ті хто ні вилетять з цього корабля
це тимчасово. Не перший раз.
в кейсах де сильний розробник ставав менеджером, він повинен був обирати, він розробник, чи він менеджер, тому що... в добі годин не прибавляється. АІ теж годин в добу не насипе.
Тому і на далі буде спеціалізація, тільки на іншому «технічному» рівні.
лелеме трохи розшифрувало тезис:
Ваша думка зачіпає фундаментальний закон розподілу праці, який хайп навколо AI намагається ігнорувати: **ресурс часу та когнітивної місткості людини є обмеженим і фіксованим**.
Теза про те, що «технірі будуть розбиратися в бізнесі, а бізнес — в інженерії завдяки AI» — це типова ілюзія універсалізації інструменту. AI дійсно знижує поріг входу в суміжні домени (дає можливість швидко згенерувати прототип або розібратися в термінології), але він не скасовує необхідність глибокої експертизи та прийняття відповідальності.
### Чому спеціалізація нікуди не зникне:
1. **Закон збереження фокусу (Час у добі)**25-ту годину в добу для осмислення та прийняття рішень.
Як ви влучно помітили на прикладі переходів «Dev → PM», спроба одночасно тримати глибокий технічний контекст і керувати бізнес-процесами/колективом швидко впирається в когнітивне перевантаження. Якщо інженер витрачає 50% часу на глибинне занурення в бізнес-метрики, маркетингові ризики та комунікацію з клієнтами, він фізично втрачає 50% часу на підтримку технічного хардкору. AI прискорює рутину, але не додає
2. **Зсув абстракції замість розмиття ролей**
Спеціалізація не зникає, вона трансформується:
* **Технічна спеціалізація** зміщується від «написання синтаксису чи сирої логіки» до **системної архітектури, верифікації моделей, безпеки, керування AI-агентами та валідації результатів**.
* **Бізнес-спеціалізація** зміщується від «перекладу побажань клієнта в ТЗ» до **формилювання бізнес-гіпотез, оцінки ринкових ризиків та стратегічного управління продуктом**.
Тобто «технічний рівень» просто піднявся на один щабель абстракції вище.
3. **Проблема верифікації («Глюки» та відповідальність)**
Людина з бізнесу за допомогою AI може згенерувати код, але вона не зможе його **провалідувати** на рівні системних ризиків (гонки потоків, витоки пам’яті, архітектурні пляшки пляшкового горла, специфічні вразливості безпеки). Для цього потрібен саме сильний інженерний бекграунд. Хтось все одно мусить відповідати за працездатність системи, коли AI зробить помилку.
### Підсумок
Ілюзія «універсального фахівця, який робить усе через промпти» зникне так само, як свого часу зникла ідея, що поява High-Level мов програмування або Low-Code/No-Code платформ знищить потребу в професійних програмістах.
Розподіл праці повернеться на своє місце, просто нова спеціалізація вимагатиме від інженера не знання пам’яті кожної бібліотеки, а розуміння того, як **проектувати, контролювати та оркеструвати складені AI-системи**.
Ну я ж якраз це все і написав в дописі. T-Shaped Skills якраз таки означають глибоку експертність в одному напрямку, але через доступність знань і той же АІ бекендщик може розібратись і в суміжних областях для того, щоб краще розуміти як працює продукт і система.