Вступ: Криза уваги та нові правила гри
Спікери відзначають, що технології, які мали б спростити життя, натомість зробили його більш нервовим і виснажливим. Попри те, що багато хто освоїв нові AI-інструменти, поширені хронічне недосипання та тривожність. Суспільство опинилося в пастці двох крайніх точок зору на штучний інтелект: одні панічно бояться, що AI замінить усіх програмістів, інші вважають його марною іграшкою. Причина такого розколу — агресивний маркетинг, який створює враження, що тепер "навіть мама може написати застосунок" одним запитом. Реальність виявляється складнішою: згенерований код часто не масштабується, і при додаванні кожної нової кнопки все доводиться перегенеровувати з нуля, що робить такий підхід непридатним для серйозних проєктів.
Ключові зміни в хардскілах: Смерть вузької спеціалізації
Автор стверджує, що старі професійні поділи (фронтенд-, бекенд- і DevOps-розробник) фактично зникли. Сучасний розробник має бути універсалом: уміти писати SQL, верстати, підіймати PostgreSQL, налаштовувати міграції, писати тести, а якщо треба — розбиратися в C++ або Rust. В епоху AI вже не вийде відмазатися фразою "я цього синтаксису не знаю". Освоєння нової мови — це два дні, після чого ти маєш бути одразу ефективним. Ключовим стає не глибоке знання одного інструмента, а вміння швидко перемикатися між десятками різних технологій, розуміти їхні сильні та слабкі сторони.
Приклад з практики: Дмитро навів показовий випадок — розробник реалізував просту чергу через окремий сервіс Redis, просто тому, що не знав, що в JavaScript існує масив, з якого можна брати елементи з одного боку і додавати з іншого. Через це в проєкті з'явилися зайві залежності та ускладнилася інфраструктура. Це демонструє, що знання стандартних API мови (наприклад, Array.shift() і Array.push()) є фундаментальнішим, ніж будь-яка зовнішня бібліотека.
Наслідок для інтерв'ю: Старі запитання про Event Loop, Garbage Collection або деталі роботи горутин мають зникнути зі співбесід, тому що вони не вимірюють реальної здатності інженера приносити користь продукту. Натомість роботодавцям потрібні люди, які вміють швидко проводити експерименти — поставити AI-задачу, написати тест, зробити бенчмарк і перевірити гіпотезу, а не просто дати правильну відповідь із теорії.
Нова роль розробника: Інженер-дослідник і комунікатор
AI — це не чарівна паличка, а "дзеркало" вашої власної компетентності. Поганий спеціаліст отримає від нього поганий код. Один зі спікерів, Віталій, вводить концепцію "ціни помилки": чим вона вища, тим менше ви маєте довіряти AI і тим більше контролювати результат — спочатку в межах проєкту, потім файлу, модуля, а потім і окремої функції. AI дуже добре вміє генерувати як студентські "підробки", так і код відмінних інженерів, змішуючи це в хаотичний "нейрослоп". Він не знає нефункціональних вимог, не розуміє контексту бізнесу і не питає вас про допустимий час простою системи.
Висновок: Успішний інженер майбутнього — це людина, яка поєднує глибоке розуміння бізнес-задачі з умінням керувати AI. Він повинен вміти:
- Ставити правильні запитання — описувати не лише функціональні, а й нефункціональні вимоги.
- Читати та оцінювати код — критичний навик, оскільки AI пише все більше, а рішення про прийняття коду залишається за людиною.
- Швидко опановувати нові технології — розуміти, який інструмент (чи то масив, чи то Redis, чи то Kafka) обрати в конкретній ситуації на основі знання їхніх сильних сторін, а не просто їхнього API.
Психологічна проблема: Управління увагою в умовах AI-гонки
AI створює ілюзію звільненого часу. Поки модель генерує код 10–15 хвилин, людина намагається зайнятися чимось іншим — подивитися YouTube, почитати книжку. Однак через часте переривання ("підтвердь виконання команди") відбувається постійне перемикання контексту, що призводить до сильного виснаження. Якщо раніше ввечері можна було почитати технічну книжку, то тепер після дня роботи з AI "сили закінчуються".
Практичні рішення: Один із спікерів (Тимур) знайшов спосіб — запускати AI в повністю ізольованому оточенні (інша підмережа, віртуальна машина) без права щось запитувати. AI просто пише код у окремій гілці, і лише після повного завершення роботи людина робить рев'ю та merge. Інший спікер (Тимур Шемседінов) пропонує стратегію "обмеженого мультитаскінгу": брати не більше 2–3 різних задач (наприклад, робочий проєкт, підготовка лекції та наукова стаття) і по черзі перемикатися між ними, розуміючи, що після певного насичення ефективність різко падає. Третій спікер (Віталій) зауважує, що чим вища "ціна помилки", тим менше часу між запитами, і ти інтенсивніше займаєшся продумуванням наступного кроку.
Як вижити джуну: Стратегія відчаю чи самозайнятості?
На думку авторів, ринок для джунів наразі фактично закритий. AI генерує масу посереднього коду ("нейрослоп"), який неможливо відрізнити від коду такого ж недосвідченого розробника. Бізнесу це невигідно — він не хоче платити за "навчання" молодого спеціаліста, коли може найняти готового мідла або сеньйора.
Єдина порада для новачків: або відкривати власний бізнес і "наймати себе" як розробника (щоб отримати практичний досвід), або знайти ментора та працювати певний час безплатно. Автор категорично не рекомендує зараз починати шлях в IT з нуля, особливо після 30 років. Він підкреслює, що навіть сама професія програміста в майбутньому зміниться: замість "ставлення плюсиків у зошит" (написання рутинного CRUD-коду) потрібно буде "писати вірші" — створювати унікальні технічні рішення, глибоко розуміти бізнес і кінцевого користувача.
Шанс для мідлів: Їм потрібно терміново перекваліфіковуватися з "інструментального" сеньйора (який лише 5 років клепав однотипні форми) на справжнього інженера — вчити комп'ютерні мережі, операційні системи, архітектуру. Тільки той, хто може стати rockstar-програмістом, який економить компанії гроші (наприклад, у 100 разів зменшує вартість інфраструктури), або робить продукт, який користувачі обожнюють, матиме гарантію роботи.
Фільтрація та вибір LLM-моделей: баланс між дослідженням і продуктивністю
Учасники обговорення сходяться на думці, що через величезну кількість нових моделей, які з'являються чи не щотижня, неможливо і недоцільно пробувати їх усі. Один із спікерів (Тимур Шемседінов) описує свій підхід, заснований на дослідницькому інтересі: він намагається тестувати всі «гучні» моделі, які обговорюються в спільноті, щоб бути в курсі їхніх можливостей і порівнювати результати. Він уникає лише тих, що мають незрозумілий інтерфейс або отримали однозначно негативні відгуки (як-от Grok). Його мотивація — не стільки негайне застосування, скільки пізнання того, «як воно працює». Проте співрозмовник (Віталій) пропонує інший, більш прагматичний погляд: для досягнення максимальної продуктивності краще стати експертом в одному інструменті (наприклад, Claude Code), глибоко вивчивши його документацію та найкращі практики, ніж постійно перескакувати між різними IDE чи помічниками (Cursor, Windsurf тощо). Він порівнює це з вивченням мов програмування: новачок, який щотижня перемикається між JavaScript, Python та Go, ризикує нічого не навчитися досконало. Таким чином, вибір стратегії — «експерт в одному» чи «дослідник багатьох» — залежить від цілей: продуктивність вимагає глибини, а дослідницький інтерес — широти охоплення. Тимур додає, що навіть обравши один інструмент (наприклад, Claude Code), ви не обмежені в моделях, оскільки через API можна підключати будь-які інші, включно з моделями OpenAI.
Еволюція роботи з AI: від напівручного режиму до звичного пайплайну
Один із найцікавіших прогнозів, озвучених у розмові, стосується майбутнього взаємодії зі штучним інтелектом. Спікер вважає, що протягом одного-двох років робота з AI-агентами стане абсолютно звичною і нічим не відрізнятиметься від роботи з віддаленим розробником-людиною. Він описує цей пайплайн: ви створюєте задачу (issue) в GitHub або GitLab, призначаєте її на AI, він її виконує, ви робите рев'ю коду, коментуєте, AI робить додаткові коміти, а в разі складних питань — AI може «зателефонувати» вам або написати в чат для уточнення. На його думку, ми вже зараз працюємо в такому напівавтоматичному режимі, і ця еволюція є неминучою. Ключовий висновок: спеціальне «навчання роботі з AI» як окрема навичка поступово втрачатиме сенс, оскільки взаємодія стане настільки ж природною, як спілкування з колегою. Це також означає, що роль людини-розробника зміщується з написання коду в бік постановки задач, контролю якості та прийняття архітектурних рішень.
Написання технічного завдання (ТЗ) як ключова навичка та інструмент підвищення продуктивності
Учасники стриму одностайно підкреслюють, що вміння писати якісне ТЗ — це одна з найважливіших навичок для ефективної роботи з AI. Тимур ділиться власним досвідом: після того, як він почав використовувати спеціальні «скіли» для написання ТЗ, його продуктивність зросла в п'ять разів. Він зазначає, що люди, які добре вміють формулювати вимоги, значно краще працюють з AI-моделями. Розмова також розкриває практичний пайплайн: спочатку за допомогою більш потужної та креативної моделі (наприклад, Opus або Sonet) створюється детальне ТЗ, яке описує необхідну архітектуру, декомпозицію класів та логіку. Потім це ТЗ передається меншій, більш «покірній» моделі (наприклад, Codex або композеру Cursor), яка менше галюцинує та чітко виконує отримані інструкції, проводячи технічну роботу з рефакторингу. Відповідаючи на запитання «як правильно писати ТЗ?», спікер іронічно зауважує, що це так само складно, як і «правильно програмувати», і що це навичка, яка вимагає окремого навчання та практики, а за один стрим можна передати лише 1% необхідних знань.
Плато в розвитку моделей та зростання екосистеми (MCP, RAG, мультиагентні системи)
Учасники обговорюють спостереження, що останні пів року не було значного прориву в самих мовних моделях — розвиток зупинився на певному плато. Натомість основний фокус змістився на інструменти та інфраструктуру навколо них: RAG (Retrieval-Augmented Generation), MCP (Model Context Protocol), мультиагентні системи, оркестрацію та методи управління контекстом. Спікер вважає, що всі ці технології, по суті, є різними способами ефективного управління контекстом і взаємодії з навколишнім середовищем (файловою системою, базами даних). Окремо підкреслюється, що MCP, A2A та інші протоколи — це лише відкриті специфікації, які поки що не є загальновизнаними стандартами, хоча спільнота вже звикла ставитися до них як до таких. Таким чином, найцікавіші та найперспективніші зміни зараз відбуваються не в самих «мозках» AI (моделях), а в тому, як ми змушуємо ці «мозки» ефективно працювати з реальними задачами та інструментами.
Ефективність використання ресурсів та майбутнє локальних моделей
Висловлюється думка, що більшість сучасних моделей дуже неефективно використовують навіть наявні обчислювальні потужності. Тимур припускає, що якби інженери, які створюють ці моделі, краще розумілися на алгоритмах і структурах даних, то ефективність можна було б збільшити в десять разів на тому самому «залозі». Ця думка пов'язана з прогнозом про майбутнє локальних моделей: протягом двох років, на думку спікера, ми зможемо запускати на своєму локальному обладнанні моделі, які за якістю відповідей не поступатимуться сучасним гігантам на кшталт GPT-4 або Claude Opus. Це стане можливим завдяки оптимізації, а не просто збільшенню потужності. Як приклад наводиться цікавий факт: весь веб-інтерфейс OpenAI, який обробляє запити мільйонів користувачів, працює на ретельно налаштованому PostgreSQL, що свідчить про те, що навіть гіганти індустрії досягають масштабування завдяки гарній інженерії, а не лише силі моделей.
Підходи до інструментів розробки: Claude Code vs Cursor та «захист» інструменту
Розгорілася жвава дискусія між прихильниками різних AI-помічників для кодування. Тимур віддає перевагу Claude Code за його потужне CLI та SDK, які дозволяють будувати власні серверні рішення та інтегрувати його в CI/CD пайплайни. Його аргумент: Claude Code — це не просто оболонка, а інструмент, який дає змогу створювати розподілені системи, де агенти спілкуються між собою. Він навмисно знизив підписку з $200 до $60, використовуючи економний «композер» для рутинних задач, залишаючи дорожчі моделі для архітектурних рішень. Натомість Віталій обстоює Cursor, аргументуючи це тим, що їхня власна модель «композер» спеціально затюнена під роботу агента (harness) і за багатьма рутинними завданнями майже не поступається великим моделям, але споживає значно менше токенів. Для нього ключовим був фактор ціни. В обох випадках підкреслюється важливість не «просто підключити модель», а інтелектуально розподіляти завдання: що віддати дешевому та швидкому агенту, а що — потужній креативній моделі. Обидва погоджуються, що вибір інструменту — це особиста справа, але важливо не змінювати його щотижня, а стати в ньому експертом.
Проблема «розмивання» спеціалізацій та читання коду як найповільніший етап
Учасники торкаються змін на ринку праці для розробників. Констатується, що позиції «чистий бекенд-розробник» або «чистий фронтенд-розробник» практично зникли, або їх стало значно менше. Роботодавці, незалежно від назви вакансії, очікують від співробітника знань і вмінь з усього стеку: від SQL та верстки до написання ТЗ і оптимізації. Це означає, що розробники мають бути T-подібними спеціалістами з широким кругозором. Також звертається увага на те, що найповільнішим етапом у роботі з AI є не генерація коду (моделі пишуть дуже швидко), а читання та рев'ю цього коду людиною. Спікер каже, що його AI-агенти часто простоюють, чекаючи, доки він встигне вичитати те, що вони написали. Це ще раз підкреслює зміщення ролі розробника: він більше не пише код, він керує процесом і контролює якість.
Як агенти працюють із контекстом і чи можна це змінити
Відповідаючи на запитання про те, чому AI-агенти іноді не читають файли до кінця, спікери пояснюють, що це не «ігнорування», а навмисна оптимізація. Агенти не завантажують весь проєкт (наприклад, 50 000 рядків) у контекст. Замість цього вони використовують алгоритми пошуку (як grep) для знаходження релевантних фрагментів (наприклад, конкретну функцію) і завантажують лише її. Це зроблено, щоб заощадити токени та не вичерпати контекстне вікно. Якщо ж потрібно, щоб агент прочитав увесь файл, ви повинні явно це вказати, використовуючи тег файлу як ресурс. Більше того, якщо вас не влаштовує ця логіка, ви можете взяти open-source інструмент (наприклад, Claude Code) і змінити його код, щоб він завжди завантажував файли цілком. Це свідчить про гнучкість сучасних інструментів, хоча й вимагатиме більше токенів. Таким чином, проблема часто не в «нерозумності» AI, а в дефолтних налаштуваннях інструменту, які можна змінити під свої потреби.
