Фулстек помер? Хай живе фулстек 2.0! Як ШІ змінює нашу професію

💡 Усі статті, обговорення, новини про AI — в одному місці. Приєднуйтесь до AI спільноти!

Продовження дискусії по темі https://dou.ua/forums/topic/55921/

Трохи про себе: Юрій Кучеренко

Продуктовий Full-stack developer.
Працюю в Державній службі зайнятості.
Стек: Node.js, NestJS,  Angular, React, Flutter

Чи забере штучний інтелект в нас роботу? Це питання, мабуть, хоч раз ставив собі кожен розробник, передивляючись стрічку новин. Звідусіль лунають гучні заяви видатних тех-гуру про те, що ще трохи, і ШІ почне писати код замість нас. Такі розмови, звісно, змушують нервувати і замислитись(трохи впадати в паніку)))): а яке місце для людини залишиться у світі, де машини кодують?

Але давайте будемо реалістами: панічні прогнози, та і в цілому прогнози, не завжди збуваються. ШІ — це неймовірний інструмент, але далеко не чарівна паличка. Він може запропонувати геніальне рішення, а може — згенерувати витончений глюк, який потім доведеться виловлювати. Тому найціннішим фахівцем буде не той, хто боїться, що його замінить ШІ, а той, хто навчиться віртуозно ним вправлятися.

1. З чого все починалося: Класичний фулстек

Щоб зрозуміти, куди ми йдемо, варто трохи повернутися назад. Ким був класичний фулстек-розробник? По суті, це людина-універсал у світі ІТ. Фахівець, який міг і фронтенд-кнопочку красиво зробити, і серверну логіку написати, і з базою даних розібратися, чи не так?

Головна причина його популярності — прагматизм та економія. Уявіть собі стартап (в моєму випадку-державна установа): грошей обмаль, часу ще менше. Замість того, щоб наймати трьох-чотирьох вузьких спеціалістів і витрачати тижні на їхню синхронізацію, можна було взяти одного універсала. Така людина могла самотужки провести проєкт від ідеї до першого релізу (MVP)- в практиці і не тільки цим обмежувалися, що значно спрощувало комунікацію та прискорювало розробку.

Отже, фулстек завжди був відповіддю на потребу бізнесу в гнучкості та ефективності. І, звичайно, це ніколи не означало, що він знає усі мови програмування — це міф ( як не загадати вислів : якщо хтось каже, що все вміє, — тікай якнайдалі...). Це просто не можливо. Він знав достатньо, щоб змусити все працювати разом.

2. Наш новий другий пілот: ШІ-асистент

З появою ШІ наша щоденна рутина змінюється повністю. Написання коду тепер — це не монолог перед екраном, а діалог. Ти ставиш правильне запитання (промпт), отримуєш відповідь, критично її оцінюєш, корегуєш і вбудовуєш у свій проєкт.

Що це змінює?

Найголовніше — зміна акцентів. Більше не треба гуглити синтаксис забутої функції чи копіпастити стандартні конфіги. Цю рутину бере на себе ШІ. А твій мозок вивільняється для більш важливішого: для архітектури, для вирішення складних бізнес-завдань, для пошуку нетривіальних рішень. Експертність тепер вимірюється не тим, скільки фреймворків ти знаєш, а тим, наскільки добре ти вмієш:

1. Ставити точні запитання. Сформулювати для ШІ задачу так, щоб отримати 90% готового рішення, а не код, який доведеться переписувати з нуля.
2. Проводити рев’ю коду від ШІ. Перевірити його на безпеку, продуктивність і приховані «костилі». Чи не створить це жахливий технічний борг через пів року?
3. Збирати пазл. Вміти об’єднувати окремі шматочки, згенеровані ШІ, в єдину, надійну та масштабовану систему.

ШІ трохи зрівнює шанси: джуніор може за допомогою асистента написати функціонал, який раніше був йому не по зубах. Але тут і криється пастка. Лише досвідчений зрозуміє, що згенерований складний SQL-запит вб’є базу даних під навантаженням. Тож досвід не знецінюється — навпаки, глибоке розуміння систем стає ще ціннішим за просте вміння писати код.

3. Зміст сучасного фулстека

Поняття «стек» теж розширилося. Раніше це була вертикаль: БД → бекенд → фронтенд. Тепер це змінилось , «стек»- ціла екосистема, що охоплює весь життєвий цикл продукту. Ось, на мою думку, його основні інструменти для цього:

• Хмари та архітектура. Це вже не просто вміння запустити віртуальну машину. Це глибоке розуміння AWS, Azure чи Google Cloud. Це вміння проєктувати системи на мікросервісах чи безсерверних функціях, щоб вони були гнучкими та витримували будь-які навантаження.Хоч ,я трохи маю зауваження , що в цілому selfhosted надійніше, але то таке).
• DevOps та автоматизація. Відповідальність не закінчується на  заливкою на гіт. Сучасний фулстек має розуміти, як його код потрапляє до користувача. Він налаштовує пакує застосунки в Docker, керує інфраструктурою через код і несе відповідальність за те, щоб код не просто працював на його ноутбуці, а стабільно функціонувала в продакшені.
• Безпека на кожному кроці (DevSecOps). Безпека — це більше не робота окремої команди, яка приходить в кінці й усе ламає. Це спільна відповідальність. Сучасний фулстек має писати код з думкою про потенційні вразливості та вбудовувати перевірки безпеки просто в процес автоматичної збірки.(Не забувати консультуватися з відповідними фахівцями з цього напрямку. Як раз тут не потрібно ловити «зіркову» хворобу.)

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

4. Від коду до клієнта: чому розробнику час думати як продакт-менеджер

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

Це означає, що потрібно розвивати нові навички:

• Говорити мовою бізнесу. Не просто виконувати таски, а спілкуватися з клієнтами та стейкхолдерами, ставити правильні запитання і докопуватися до суті їхніх потреб. Знаю це важко, але в принципі допомагає уникнути ефекту «чорного» ящику, коли хтось,щось не так передав чи так думав.
• Бути адвокатом користувача. Пам’ятати, що за кожною фічею стоїть жива людина. Приймати технічні рішення, які роблять її життя, а не життя розробника, простішим і приємнішим. Простіше — клієнт завжди прав, ну не завжди, але то вже як повезе.
• Відповідати за результат. Взяти на себе відповідальність за весь шлях: від ідеї та розробки до запуску, аналізу метрик і подальших покращень. Це не так легко ,як здається, з досвіду знаю — іноді колеги готові виконувати лише чіткі інструкції, щоб в разі чого- так написали)).

На порозі нового часу

Так хто ж такий фулстек-розробник 2.0? Це вже не просто кодер. Це технолог, стратег і архітектор бізнес-рішень — «all inclusive» в галузі ІТ. Це людина, яка не просто володіє набором інструментів, а вміє вибрати правильні, з’єднати їх у надійну систему та спрямувати на досягнення конкретних бізнес-цілей.

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