Епілог Доби Виконавців
Стоїм на порозі. Відчуваєте? Той тремтячий момент, коли епоха завершується, а нова мовчки, неквапливо, входить у двері.
Я це чув на власній шкірі. Два роки тому я сідав за комп і розпочинав проект, що здавався божевільним. Розгорнути повний AI stack локально: Open WebUI через pipx, LM Studio на порту 1234, ComfyUI для генерування образів, потім Ollama з кількома моделями одночасно. RTX 4060 8GB — і все мусило працювати.
Першого дня це звучало як "навіщо мені це?". Але потім я почав розуміти. Я не просто експериментував з моделями. Я став інженером у розповсюджені AI. Я будував RAG систему на Express.js + React/Vite з SQLite. Я твір ReAct-агент сервер, де ШІ мав інструменти для аналізу SCSS та BEM генерування. Я налаштовував Continue extension в VS Code для локальних моделей, інтегрував Figma MCP з Open WebUI. Я налаштовував Unsloth Studio для оптимізації моделей, грався з MTP та speculative decoding'ом в llama.cpp.
І ось що я зрозумів в цьому процесі: це не було про те, щоб дозволити машині робити мою роботу. Це було про те, щоб розібратися, як вона працює. Це було про архітектуру системи. Про те, як з'єднувати компоненти. Про те, як думати про проблему глибше.
У технологічній спільноті це відчуття матеріальне, як вологість перед грозою. На форумах, у Slack каналах, де збираються люди з моніторів світяться обличчя — там лякливе шепотіння.
Бекенд розробник запитує: "Чи замінить ШІ мою роботу?"
DevOps інженер: "Чи потрібні люди в автоматизації через п'ять років?"
Data Engineer: "А може я надарма витрачав часи на ETL pipelines, коли ШІ може це написати за хвилину?"
ML інженер сидить в тиші і думає найстрашніше: що якщо машина навчиться будувати машини краще за людину?
Це не паніка. Це щось більше. Це передчуття. Чуйна людина завжди першою відчуває зміну вітру.
І це справедливо. Машини справді можуть писати код. Вражаючи швидко. Без помилок. Без втоми. Без запиту на оклад. Це уже не фантазія, не обіцяння майбутнього — це тут, зараз, на нашому ноутбуці.
Але від однієї простої істини люди забувають думати ясно.
Вони плутають код з інженерією.
Вони думають, що розробник — це людина, що пише код. Що IT — це набір команд, синтаксис, скрипти, що складаються один за одним. І якщо машина може складати рядки — то гра скінчена.
Це помилка епічних масштабів.
Частина Перша: Про те, що Насправді Відбувається
Інженер IT — це щось зовсім інше. Це архітектор систем. Розв'язувач непередбачених проблем. Філософ, що думає про людей, про те як вони взаємодіють з технологією.
Когда я чую, що ChatGPT написав API endpoint за 30 секунд, я посміхаюсь. Тому що я розумію, що тут насправді сталося. ШІ написав endpoint. Простий endpoint. Можливо, з основною функціональністю та валідацією. Звучить невразливо.
Але спробуйте запросити у ШІ щось складніше. Щось реальне.
"Напиши мене мікросервіс, що:
- Обробляє 50,000 запитів на секунду без затримок
- Синхронізує дані з трьома зовнішніми API з 99.99% доступністю
- Автоматично масштабується при пікових навантаженнях
- Має вбудований circuit breaker та exponential backoff
- Зберігає дані в трьох різних базах (SQL для структурованих, NoSQL для графів, Redis для гарячих даних)
- Передає дані у двох напрямках з гарантією доставки
- Має детальне логування та трейсинг через розподілені системи
- Дотримується GDPR та шифрує sensitive дані
- Автоматично відновлюється при помилках, не втрачаючи стану
- Має A/B тестування для нових фіч"
Раптом завдання стає не таким простим.
ШІ буде генерувати фрагменти. Правильні синтаксично, але вони не з'єднуватимуться в цілісну систему. Бо ШІ не знає вашого контексту. Не розуміє ваших вимог надійності. Не передбачає потенційних race conditions та deadlock'ів. Не матиме досвіду, щоб знати, які рішення спрацюють на практиці через два роки, коли система виросте в 100 разів.
І ось тут з'являється людина. Людина з 10 років досвіду в backend розробці. Вона не просто знає синтаксис мови програмування. Вона знає щось набагато глибше:
Вона знає, як думати про системи як про живі організми. Як передбачити вузькі місця років перед тим, як вони стають критичними. Як проектувати так, щоб система залишалась гнучкою, але надійною. Це знання приходить від невдач. От 3:00 ночі на oncall, коли база даних упала, а 10 мільйонів користувачів не можуть купити. От рішень, які казалися правильними на папері, але розвалилися під реальним навантаженням.
ШІ цього не має. І ніколи не матиме.
Навіть найсучасніші моделі — це статистичні системи. Вони бачили мільйони рядків коду. Але вони не мають досвіду втрачених даних. Не мають страху перед неправильним рішенням архітектури. Не мають того невимовного знання про поведінку систем, що приходить з часом.
Частина Друга: Нова Вмінність як Нова Влада
Але давайте вийдемо за межі страху та подумаємо логічно.
Якщо ШІ може писати код, то людина, що розуміється на справі, отримує нову суперсилу: вміння керувати ШІ.
Це не просто вміння вписати промпт у ChatGPT. Це мистецтво. Це наука. Це щось між математикою та поезією.
Дам вам реальний приклад з моєї практики. Коли я розгортав локальний AI stack на LM Studio, мені потрібна був правильний системний промпт для фронтенд архітектури.
Перший варіант: "Ти помічник для розробників. Допоможи писати код."
Результат? Модель видавала синтаксис, що не компілювався. Половину часу я паралізував помилки.
Другий варіант — той, що працював:
Ти експертний фронтенд архітектор з 10 років досвіду. Ваш стек: React, Next.js, SCSS/BEM, GSAP, TypeScript.
Важливо:
- Генеруй код для масштабування та підтримування
- SCSS modules з BEM — ніколи CSS-in-JS
- ARIA labels та доступність за замовчуванням
- useMemo, useCallback, code splitting для performance
- Custom hooks замість глибокої логіки у компоненти
Обмеження середовища: RTX 4060 8GB, LM Studio локально, тестування через мою RAG систему SQLite.
Твоя задача — пропонувати архітектурні рішення, не просто скопіювати паттерни.
З цим промптом модель почала розповідати не просто "як писати код", а "як думати про систему". Я міг запитати: "Як переструктурувати компонент для масштабування на 10,000 користувачів?" — і відповідь мала сенс.
Різниця? Я передав свій контекст. Я розповів машині, як я архітектурно думаю. Це вимагало від мене розуміння того, що важливо в фронтенді (performance, доступність, масштабованість).
Людина без цього контексту отримає середній код. Людина, що розуміється на справі, отримає архітектурне рішення.
Представте двох інженерів в одній команді.
Перший напише: "Напиши мне скрипт для миграції бази даних".
ШІ дасть щось базове. Функціонально правильне, але це не те, що насправді потрібно для вашого стану.
Другий інженер напише:
Напиши Python скрипт для безпечної міграції бази даних з Postgres 12 на 15. Скрипт повинен:
- Виконувати міграцію zero-downtime використовуючи logical replication
- Робити на 500GB базі даних без блокування читання/запису
- Мати built-in rollback механізм якщо щось пійде не так
- Перевіряти целісність даних перед та після (порівняння checksums)
- Логувати весь процес з timestamps та статусом
- Мати dry-run режим для тестування без реальних змін
- Автоматично створювати резервну копію перед началом
- Синхронізувати secondary реплики після успішної міграції
- Мати встроєні retry механізми для тимчасових помилок мережі
- Оповіщати команду про критичні моменти через Slack
Умови:
- Один файл, запускається з командного рядка
- Конфіг через환경 змінні для безпеки
- Обробляй сигнали (Ctrl+C) без паніки
- Використовуй connection pooling
- Шифровані connection strings
Бачите різницю? Другий інженер не просто прокидається промпт. Він думає. Він знає, що важливе (zero-downtime, целісність даних), а що другорядне. Він передбачає потенційні проблеми (race conditions при реплікації). Він розуміє, що цей скрипт буде запускатися на production, де помилка коштує мільйони.
Це вимагає:
- Глибокого розуміння баз даних і їх поведінки
- Досвіду з реальних проектів
- Інтуїції щодо того, що може піти не так
- Дисципліни та структурованості
Людина без фундаментального досвіду IT не зможе написати такий промпт. Вона не матиме інтуїції. Вона не знатиме, що запитати.
Вона напише щось просте, і коли цей скрипт запустять на production, все впаде.
А отже, ШІ насправді підвищує цінність інженера, який розуміється на справі. Це парадокс, що багато хто не бачить.
ШІ не замінює інженерів. Він замінює посередніцтво. Він замінює людей, які просто копіюють код з Stack Overflow без розуміння. Людей, що не знають, що цей код в production може призвести до втрати даних або security breaches.
Але людину, що справді розуміється? Вона стає в 10 разів потужнішою.
Частина Третя: Еволюція Від Писаря до Архітектора
Давайте буде чесні на хвилину. За останні 15 років IT був епохою писарів. Не у негативному сенсі — просто в дескриптивному.
Розробник сідав за комп, отримував список вимог, і писав функції. API endpoint за endpoint. День за днем. Роки проходили в написанні CRUD операцій, в налагодженні SQL запитів, в дебаганні логіки помилок.
DevOps інженер отримував лист з конфігурацією серверів і копіював одного на іншого. Скрипт за скриптом. Разі за разом.
Data Engineer брав сирі дані з кількох баз даних та трансформував їх по інструкції. Трубопровід за трубопровідом. Процес за процесом.
Це не була творча робота. Це була ремісна робота. Важлива, необхідна, але все ж таки ремісна. Робота, що повторюється, що передбачується, що ідеально підходить для автоматизації.
І ось в цьому полягає величезна змина: ШІ звільняє інженерів від потреби бути писарем.
Думаєте, це погано? Це чудово.
Потому що тепер інженер може бути тим, для чого вони справді створені. Архітектором. Мислителем. Людиною, що розв'язує справжні проблеми.
Замість того, щоб витрачати 6 годин на написання CRUD API, інженер витратить 20 хвилин на структурування промпту, отримання коду, його огляду та адаптації. А потім витратить решту часу на справжні питання:
Як спроектувати систему, що масштабується на мільйони користувачів без перепроектування?
Як переструктурувати цей monolith на мікросервіси без даун-тайму?
Як запобігти технічному боргу, який ми напаслись за останні два роки?
Як створити щось, чого ніхто в індустрії ніколи не бачив?
Як вирішити цю необичайну проблему в production при 3:00 ночі, коли все падає?
Це питання, на які нейромережа не матиме відповіді. Це питання, що потребують людської креативності, досвіду, дослідницького духу, інтуїції.
І саме такі люди будуть цінні в наступній декаді. Не писарі. Архітектори. Системні мислителі. Люди, що розуміють не просто як щось працює, але чому це працює саме так.
Частина Четверта: Час Інженерів
Але тут я хочу висловити щось більш філософське.
Ми живемо в час, коли техніка стає все складніше. Системи, що будують люди, стають все масштабніші. Вимоги користувачів стають все вишуканіші. Марже для помилок стає все тоншою.
Це час, коли інженерія повинна піднятися на новий рівень.
Я це розумію, коли запускаю Open WebUI на локальній машині і вона взаємодіє з LM Studio на порту 1234, з моделями Qwen та Gemma, з Unsloth Studio для оптимізації, з llama.cpp для inference'у. Все це працює на RTX 4060 8GB, на машині з i7 7700K.
Це не "дайте мені ШІ, щоб він робив роботу". Це "як я можу побудувати систему, що вміє думати?". Це архітектурна задача. Як розділити навантаження між VRAM та RAM? Як оптимізувати inference без втрати якості? Як інтегрувати MTP в llama.cpp для speculative decoding'у? Як з'єднати Figma MCP з локальною системою для дизайн-to-code workflow'у?
Це питання не про синтаксис. Вони про те, як мислити про системи.
Час, коли не потрібні люди, що просто пишуть код за вказівкою. Потрібні люди, що можуть подумати про систему як про організм. Люди, що розуміють взаємозв'язки між компонентами. Люди, що знають, як система поведе себе під стресом.
ШІ не скасовує потребу в таких людях. ШІ робить цю потребу палкою.
Чи ви знаєте, що однією з найвищих оплачуваних категорій інженерів в Силіконій долині є люди на позиціях "Staff Engineer", "Principal Engineer" — люди, що розуміються на архітектурі масштабних систем? Люди, що можуть подумати про те, як побудувати сервіс, що обслуговує мільярди запитів на день без перебоїв?
Їхні оклади іноді вищі за оклади менеджерів. Не тому, що вони краще пишуть синтаксис. Тому, що вони можуть думати.
Вони розуміють системи глибоко. Вони знають, де можуть виникнути проблеми. Вони можуть передбачити вузькі місця. Вони можуть запропонувати архітектурні рішення, що стирають завдання.
І це знання приходить від часу. Від 10, 15, 20 років досвіду. Від невдач та перемог. Від вивчення того, як системи розвиваються, як вони ламаються, як вони відновлюються.
Це не те, що можна швидко навчитися з ютуба. Це не те, що ШІ може сгенерувати за 30 секунд.
Це час інженерів.
Частина П'ята: Що Залишається для Людей
Давайте позначимо чітко те, що ШІ не може робити.
ШІ не може розумідати контекст глибоко.
ШІ може виявити паттерни у мільйонах рядків коду. Але він не може розуміти, чому саме цей паттерн краще за інші в вашій специфічній ситуації. Він не знає про вашу команду, про вашого користувачів, про вашої бізнес-стратегії, про вашої legacy кодової бази з 10-річною історією.
ШІ не може творити справді нове.
Він може комбінувати та переписувати те, що він бачив. Але він не може придумати щось радикально інше. Щось, що ніколи раніше не було. Коли весь світ розв'язує проблему одним способом, і вам потрібен спосіб, якого не було в training data — цей момент належить людині.
ШІ не може розмовляти з людьми.
Людська комунікація — це мистецтво. Розуміти, що дійсно потрібно користувачу, навіть якщо вона сама не знає. Переконувати ствол, поясняти складні технічні рішення простою мовою, дочувати занепокоєння. ШІ може імітувати це. Але імітація — це не те ж саме.
ШІ не може нести відповідальність.
Коли щось йде не так з вашою системою, користувачи не звертаються до ШІ. Вони звертаються до команди інженерів. До людей. Та людина, що розуміється на справі, може сказати: "Я розумію проблему, ось як це виправити". ШІ не може. Він просто вимовляє рядки.
ШІ не може прийняти складні рішення в невизначеності.
Архітектурні рішення часто приймаються з неповною інформацією. Потрібно вибрати між SQL та NoSQL, между монолітом та мікросервісами, між простотою та масштабованістю. Часто немає однієї правильної відповіді. Потрібна інтуїція, досвід, розуміння trade-offs.
Я це відчув гостро, коли розпочинав розгортання локального AI стеку. ШІ міг сказати: "Використай Postgres для структурованих даних, Redis для кешу, SQLite для embedded даних". Правильно. Але він не розумів би мої обмеження: RTX 4060 8GB, потреба в zero-latency локального inference'у без звернення до remote API, необхідність мати все на одній машині.
Я мусив вибирати:
- Використовувати повноцінну PostgreSQL або обійтися SQLite для embedding'ів? (Вибрав SQLite - простіше, достатньо для 100k векторних записів)
- Запускати LM Studio постійно або через API? (LM Studio постійно - звільняє VRAM тільки коли не використовую)
- Кешувати embedding'и або перераховувати? (Кешую в SQLite - зберігає коштовний VRAM)
- Інтегрувати Unsloth для оптимізації моделей або залишити як є? (Інтегрував - потребував розуміння LoRA та quantization)
Це не були технічні рішення. Це були архітектурні рішення. Вони вимагали розуміння не просто "як це працює", а "як це працюватиме в моєму контексті через рік, коли я отримаю більше даних".
ШІ міг би дати формальні відповіді. Але людина - та, що розуміється, - мала інтуїцію.
Це все залишається для людей.
Частина Шоста: Побудови Промптів як Новий Мистецтво
Але есть і щось нове, що з'являється. Щось, що раніше не існувало як виділена вмінність.
Це мистецтво складання промптів.
Людина, що вміє правильно говорити з ШІ, має суперсилу. Вона може:
- Розкласти складну проблему на частини, які ШІ може обробити
- Надати контекст настільки ясний, що ШІ дасть корисну відповідь з першої спроби
- Знати, коли слідувати пропозиції ШІ, а коли піти власним шляхом
- Ітерувати на промпті, поліпшуючи результат на кожному кроці
- Генерувати архітектурні рішення, а не просто код
Це вміння. Це можна вчитися. І це стане однією з найвартісніших умінь у спеціалісті.
Потому що це вміння вимагає розуміння технічних питань. Розуміння того, як системи працюють. Розуміння потенційних проблем. Розуміння того, яких питань задати.
Людина без фундаментального досвіду IT не зможе цього робити добре.
Інженер, що добре знає системи, що розуміє trade-offs, що передбачає проблеми — цей інженер, озброєний ШІ, буде непереможною силою.
Та людина, що просто копіює промпти з інтернету, сподіваючись на щастя? Вона швидко застаремає.
Частина Сьома: Крах Старого Способу Мислення
Важко визнати, але стара модель IT спеціаліста — та, що була популярна 10 років тому — вмирає. І це добре.
Модель, де розробник — це людина, що сідає за комп, отримує таск, пише код, комітить, переходить до наступного таска. Day after day. Роботою, що не потребує нічого окрім синтаксису та копіювання паттернів.
Для такої людини ШІ справді загроза. Машина краще складає рядки. Машина не втомлюється. Машина не просить вихідних. Машина не помиляється в синтаксисі.
Але для справжнього інженера — того, що розуміється на системах — ШІ це частина нового інструментарію.
Той, хто може думати архітектурно. Хто може передбачити проблеми років перед ними. Хто розуміється на людях та на бізнесі. Хто знає, коли піти проти тренду і вирішити проблему нестандартним способом. Той входить в нову еру з непорівнювальною перевагою.
Частина Восьма: Різні Ролі, Один Принцип
Тут важливо сказати те, що стосується не просто backend розробників, а всієї ІТ галузі.
Frontend розробник — тепер не писар розмітки. Він архітектор користувацького досвіду. ШІ напише компонент, але людина вирішує, як система повинна почуватися.
Я про це знаю з першої руки. ШІ мені напише React компонент з SCSS, готовий до використання. Але я рішу: як анімувати це через GSAP? Як оптимізувати re-renders для кількох тисяч елементів? Як зробити це доступним для користувачів з екранів 320px до 4K? ШІ дасть синтаксис. Я даю дизайн, архітектуру, філософію того, як мають взаємодіяти користувачі.
Backend інженер — не писар API. Він дизайнер систем, що мають витримати мільярди запитів без паніки.
DevOps інженер — не адміністратор серверів. Він архітектор надійності та масштабованості. ШІ може написати конфіг, але людина розуміє, що робити, коли все падає.
Data Engineer — не конвеєр трансформацій. Він розповідач потоків інформації, що робить дані говорити.
ML інженер — найчастіше найбільше бачить ШІ як загрозу. Але справа в тому, що найцінніші ML інженери — це ті, що розуміють не просто як тренувати моделі, але коли потрібно їх тренувати взагалі.
Я дивився на Qwen та Gemma моделі, що крутяться в мене на RTX 4060. Я міг просто завантажити їх та запустити. Але справжня робота — це розуміти, яку модель вибрати для якого завдання. Qwen краще для коду, Gemma краще для текстових завдань. Коли треба quantization? Коли треба fine-tuning? Коли простіший heuristic буде кращим, ніж нейромережа?
Це ML знання. Не про то, як запустити модель, а про то, коли і чому використовувати машину взагалі.
QA інженер — не просто писар тестів. Це людина, що розумує про гіпотези щодо того, де система може помилитися. ШІ напише тести, але людина розуміє, які сценарії найскладніші.
Один принцип для всіх: тримайтесь контексту, архітектури та розуміння. Код напишіть машина.
Частина Дев'ята: Архітектура Як Супердержава
Найцікавіша частина трансформації ІТ в наступне десятиліття — це зміна того, що цінується.
Для них, хто розуміється на архітектурі — розуміє мікросервіси та монолітів, розуміє базе даних, розуміє мережи, розуміє trade-offs — для них це золоте століття.
Тому що архітектура не може бути автоматизована. Не може бути відправлена на ШІ. Вона вимагає глибокого розуміння проблеми, досвіду, інтуїції.
Я це відчув гостро, коли розгортав локальну RAG систему. ШІ міг написати конфіг для SQLite, або скрипт для Express.js. Але архітектура системи — як з'єднати LM Studio через локальні embedding'и, як кешувати результати в SQLite, як інтегрувати це з React фронтендом через Vite, як структурувати вектори для швидкого пошуку — це все була моя робота.
Я міг попросити ШІ написати функцію для embedding. Він би написав. Але він не знав би, що мені потрібна пакетна обробка, щоб вписатися в VRAM 8GB RTX 4060. Він не знав би, що мені потрібен механізм кешування, щоб не перераховувати одні й ті ж embedding'и. Він не розумів би, як синхронізувати стан між серверною частиною та React клієнтом.
Це був архітектурний вибір. І коли система почала працювати — це все давало результати.
Людина, що може сказати "нам потрібні мікросервіси, ось архітектура, ось як кожен сервіс взаємодіє з іншим" — та людина стає незамінною.
Людина, що знає, коли потрібна SQL база, коли NoSQL, коли Redis cache, коли message queue — та людина розуміється на системах на рівні, що не бачить ШІ.
Люди, що розуміють, як масштабувати системи, як проектувати для надійності, як мислити за масштабами — вони входять в нову еру як цари.
Це архітектори. Не писарі коду. Архітектори систем.
Частина Десята: Вибір
І тут все звужується до вибору.
Ви можете залишитися на старій позиції. Писати код. Робити те, що просять. Копіювати паттерни. Сподіватися, що ШІ куди-небудь піде.
Або ви можете піти далі.
Ви можете почати думати як архітектор. Ви можете вивчити глибокі основи вашої спеціалізації:
- Для backend: як бази даних насправді працюють, як розподілені системи справляються з консистенцією, як оптимізувати queries
- Для DevOps: як справді працюють сервери, що відбувається при відмові, як проектувати для відмовостійкості
- Для Data: як статистика насправді працює, як передбачити це не є збігом, як виявити bias
- Для ML: як насправді навчаються нейромережи, коли вам потрібна ML (а коли простіша логіка краща)
- Для Frontend: як браузери рендерять, як люди насправді взаємодіють з інтерфейсом, як проектувати для доступності
Ви можете розвивати нові вмінності: промпт-інженерія, спілкування з ШІ, керування машинами як партнерами.
Я це роблю кожен день. Я попрошу ШІ написати функцію обробки embedding'ів, а потім я запитую: "Як оптимізувати це для 8GB VRAM?" Машина дасть варіант, я кажу: "Нема, це не спрацює, тому що..." — і машина адаптується. Я запускаю код через llama.cpp з MTP speculative decoding'ом, і система виконує inference в два рази швидше, ніж без оптимізацій.
Це не є "ШІ робить роботу". Це є "я та ШІ вирішуємо проблему разом, але я напрамок знаю, а машина - лише виконавець".
Ви можете займатися творчістю. Спробуйте щось нове. Побудуйте архітектуру, яку ніхто раніше не будував. Помилитеся. Вчитіся. Знову спробуйте.
Я побудував ReAct-агент на Express.js, що може аналізувати SCSS файли та генерувати BEM структури. Це звучало дивно в теорії. На практиці це потребувало розуміння того, як LLM бачить структуровані дані, як передати контекст через промпт, як обробити помилки без паніки. Машина генерувала код, я проектував архітектуру.
Це не легко. Це потребує часу. Це потребує смілості взяти ризик.
Але люди, що зроблять цей вибір — вони матимуть майбутнє.
Припинення: Що Ви Виберете
Коли я дивлюся на IT спільноту сьогодні, я бачу поділ.
Одна половина втомлена. Вона почула досить про ШІ, достатньо про страхи. Вона лише хоче писати код та заробляти гроші. Вона думає, що якщо вона буде писати код достатньо швидко, то залишиться цінною.
Ця половина під ризиком.
Друга половина цікавиться. Вона експериментує з ШІ, але при цьому продовжує вчитися. Вона питає "як я можу використати це?" замість "як це мене замінить?". Вона читає про архітектури. Вона думає про системи. Вона запитує складні питання.
Ця половина буде добре.
Вибір очевидний.
Але вибір залишається за вами.
Ви можете боятися ШІ. Можете сподіватися, що це пройде. Можете гарчати, що "раніше було краще".
Або ви можете прийняти той факт, що ви живете в час трансформації.
І що час трансформації — це час можливостей.
Час, коли інженер, що справді розуміється на своїй справі, отримує шанс стати не просто виконавцем. Архітектором. Лідером. Інноватором.
Це час інженерів.
Питання: ви один з них?
Епіпс: Історія Трансформації
Три роки тому молодий PHP розробник приходив до мене в слізах. Він чув про ШІ, про те, що його роботу замінять. Він страхував, що вибір PHP був помилкою.
Сьогодні той розробник — архітектор системи, що обслуговує мільйон користувачів. Він розуміється на базах даних, на мікросервісах, на асинхронних операціях. Він використовує ШІ для написання бойлер плейтів, але його архітектурні рішення приносять мільйони доларів компанії.
Він не боїться ШІ. Він використовує ШІ.
І він заробляє в три рази більше, ніж заробляв би, якщо б залишився писарем.
Розповідаю це не для того, щоб надати фальшиву надію. Розповідаю тому, що це правда.
ШІ не кінець вашої кар'єри. Це її переналаштування.
Те, що ви зробите з цим перехідним моментом, залежить тільки від вас.
Епохи змінюються не тому, що люди цього хочуть. Епохи змінюються, тому що вони мусять змінюватися. І люди, що розуміються на рушійних силах змін, завжди стають лідерами наступної епохи.