Компанія Anthropic нещодавно запропонувала своїй команді з розвитку найняти більше менеджерів продуктів, а не менше. Причина, як повідомлялося в галузевих оглядах, полягала в тому, що Claude Code непомітно перетворив їхню інженерну організацію на команду, яка випускає продукт приблизно втричі швидше, ніж це дозволяє фактична кількість співробітників, і вузьким місцем стало вже не середовище розробки (IDE), а люди, які вирішують, що саме будувати.
Цю деталь легко пропустити в шумі будь-яких заяв про продуктивність ШІ. Водночас це структурна зміна, через яку зараз проходить решта індустрії. Вузьким місцем у розробці програмного забезпечення більше не є написання коду. Це прийняття рішення щодо того, що писати. І інженери, які ставляться до цього як до проблеми інших, скоро досягнуть плато.
Протягом більшої частини останнього десятиліття це рішення залишалося за кимось іншим. Інженерія програмного забезпечення була ремеслом, яке ви засвоювали повільно, а потім практикували у довгій, передбачуваній послідовності: глибоко занурюйтесь у технології, пишіть код, звертайтеся до Stack Overflow, коли виникають проблеми, ескалюйте до старшого інженера, коли Stack Overflow не допомагає, випускайте завдання. Менеджер продукту відповідав за потік завдань. Інженер відповідав за реалізацію. Обидві сторони сприймали цей поділ як незмінний закон фізики.
Потім цей потік скоротився за п’ять кроків.
Коротка історія стиснення робочого дня інженера
Ера Stack Overflow (2014 – кінець 2022): Мислення інженерів зосереджувалося в одному місці. Але кількість нових щомісячних запитань на Stack Overflow зараз приблизно на 77% менша, ніж у листопаді 2022 року, що невипадково збіглося з запуском ChatGPT. Це зниження — не оцінка сайту, а референдум щодо робочого процесу, який він представляв.
Ера вкладок браузера (кінець 2022 – 2024): Перше покоління ChatGPT існувало поза IDE. Інженери дотримувалися того ж циклу, що й завжди, але з швидшим оракулом: введіть запит у браузері, скопіюйте відповідь у VS Code, повторіть. Робота все ще була однопотоковою та керованою інженером. Ефективність була реальною, але локальною.
Ера IDE-native (2024 – 2025): Cursor та Claude Code перенесли модель всередину редактора та надали їй доступ до всього репозиторію. Шлях ескалації до старшого інженера значною мірою розчинився. Роками серед досвідчених інженерів панувала думка, що Bash має найдовший термін придатності серед усіх інструментів у стеку. До 2026 року для значної частки розробників, що працюють, першою командою, введеною в новий термінал, буде claude.
Ера специфікацій (2025 – 2026): Більші контекстні вікна перетворили роботу в рамках однієї сесії на те, що раніше вимагало завдань, проектних документів та спринтів. Команда Amazon Kiro IDE, за повідомленнями, скоротила час створення функцій з двох тижнів до двох днів, використовуючи той самий робочий процес, керований специфікаціями, який вони випускали. Команда інженерів AWS описала 18-місячну реархітектуру, яка спочатку планувалася для 30 інженерів, але була завершена 6 людьми за 76 днів. Вузьким місцем перестала бути швидкість написання коду. Ним стало те, наскільки чітко команда може описати, як виглядає правильне рішення.
Ера рутин (2026): У квітні Anthropic випустила Claude Code Routines: заплановані, постійні агенти, які працюють за розкладом, за webhook-запитом або вночі, коли ноутбук закритий. Cron повернувся. Hooks повернулися. Робота інженера тепер полягає переважно в оркестрації: запустити рояк перед сном, переглянути стопку pull-запитів вранці. Сторонні обгортки, як-от OpenClaw, яка була тимчасово припинена Anthropic у квітні перед частковим відновленням, говорять про те саме з боку open-source.
Вузьке місце змістилося; більшість команд – ні
Інженерія зросла приблизно втричі. Продуктовий менеджмент не змінився. Традиційне співвідношення PM до інженерів 1:8, яке вже було напруженим, тепер фактично виглядає як 1:20, оскільки кожен інженер випускає більше продукту за день. Наприклад, LinkedIn замінив свою програму для асистентів менеджерів продуктів на програму “Product Builder”, яка навчає загальних спеціалістів з продукту, дизайну та інженерії. Anthropic наймає більше PM, а не менше. Ця тенденція послідовна в компаніях, які фактично впровадили агентні робочі процеси у виробництво: система генерує готові функції швидше, ніж приймаються рішення про те, що саме слід створювати.
Для інженерів це найважливіший кар’єрний сигнал десятиліття, і його найлегше пропустити, поки стрічка новин заповнена історіями про продуктивність.
Фундаментальні принципи важливіші, а не менш важливі
Інстинкт оголосити фундаментальні знання застарілими в еру агентів абсолютно хибно трактує тенденцію.
Коли витік пам’яті призводить до збою виробництва о 3 ранку, і причиною виявляється тонка помилка власності, допущена 4 роки тому, жоден агент, що існує зараз, не зможе повністю вирішити цю проблему. Операційні системи, мережі, конкурентність та плани запитів все ще визначають, хто може вирішити реальний інцидент. Вони також визначають, хто може помітити моменти, коли результат роботи агента виглядає поверхнево правильно, але насправді є тихо, дорого помилковим. Агент, який написав 70% коду в сучасному репозиторії, не може надійно сказати нікому, де його припущення щодо безпеки потоків, володіння пам’яттю або ізоляції транзакцій розійшлися з середовищем виконання. Інженер, який може прочитати diff і виявити це, — це інженер, який потрібен команді, і такий інженер будується на фундаментальних знаннях, а не на навичках написання запитів.
Наслідком цього є те, що фундаментальні знання тепер є навичкою для збільшення ефективності, а не гігієнічною навичкою. У 2014 році знання про те, як працює повторна передача TCP, дозволяло швидше закрити квиток на налагодження. У 2026 році ті самі знання запобігають випуску регресії в масштабі всієї конвеєрної лінії випуску, керованої агентами. Сфера впливу інженера, який знає, що відбувається “під капотом”, зросла, а не зменшилася.
Рецензування – це нове написання
Інженери у 2026 році генерують код зі швидкістю, яка перевищує можливості будь-кого з них уважно його прочитати. Команда, яка швидко випускає продукт і виживає, — це команда, інженери якої ставляться до рецензування коду, згенерованого ШІ, щонайменше з таким же ретельністю, яку вони раніше приділяли його написанню. Опитування Stack Overflow за 2025 рік показало, що 84% розробників використовують інструменти ШІ, причому 46% стверджують, що не довіряють результатам, що різко зросло порівняно з 31% у попередньому році. Цей розрив, інтенсивне використання у поєднанні з низькою довірою, — саме там, де навички рецензування тепер мають найбільше значення. Кодери, які багато віддають і мало рецензують, накопичують борг, який настане під час першого реального інциденту, і інженер, який може його погасити, — це той, хто поєднав свій обсяг роботи з глибокими фундаментальними знаннями задіяних систем.
Новий диференціатор – продуктовий пайплайн
Обидва ці аспекти є необхідними. Жоден з них не є достатнім. Інженер, який має значення у 2026 році, – це той, хто перестав чекати, доки пайплайн надійде у вигляді Jira-квитка.
Це означає робити речі, які роль історично могла пропускати.
Спілкуйтеся з клієнтами. Спостерігайте, як вони фактично використовують продукт. Читайте чергу підтримки. Присутні на дзвінках із продажу. Сигнал, який продуктова команда отримує через три рівні узагальнення, інженер тепер може отримати безпосередньо за один день.
Генеруйте ідеї, а не лише оцінки. Менеджер продукту, який раніше шукав ідеї для 8 інженерів, не може шукати ідеї для 20 з такою ж якістю. Інженер, який з’являється з підтвердженою, масштабованою можливістю, більше не робить роботу PM. Інженер робить роботу, якої вимагає нове співвідношення.
Працюйте, відштовхуючись від клієнта. Amazon пише прес-реліз першим протягом двох десятиліть. Ця дисципліна добре переноситься на команди з однієї людини та на рої агентів. Обидва генерують багато робочого програмного забезпечення в неправильному напрямку без чіткого визначення того, що означає “перемога клієнта”, перш ніж буде написаний будь-який код.
Припиніть ховатися за пропускною здатністю. Чесна відповідь на запитання “Чи є у вас потужності для цієї ідеї?” раніше була “Ні”. Завдяки рутинам, хукам та кооперативному стеку агентів, чесна відповідь ближча до “Наскільки цінна ця ідея?”. Це інша розмова, і її набагато важче вести без реального погляду на клієнта.
Що винагороджуватиме наступне десятиліття
П’ятифазна історія вище – це не стільки історія інструментів. Це історія того, яку частину роботи мав виконувати людина. Частина, яка залишається людською, і яка залишатиметься людською у найближчому майбутньому, піднялася вгору по пайплайну: від набору тексту, до рецензування, до прийняття рішень, до вибору клієнта, якому служити, та проблеми, яку вирішувати.
Версія чудового інженера 2026 року – це не той, хто пише найбільше коду. Це той, хто знає, що будувати, може довести, що це варто будувати, і має флот агентів плюс дисципліну рецензування, щоб випустити це, не дозволивши системі колапсувати під власною швидкістю.
Інженери, які усвідомлять це, проведуть наступне десятиліття, виконуючи найцікавішу роботу, яку будь-коли бачило програмне забезпечення. Інженери, які чекатимуть на квиток, проведуть його, спостерігаючи, як квиток пише агент поруч із ними.
Ішан Гупта – інженер-програміст в Amazon.
Ласкаво просимо до спільноти VentureBeat!
Наша програма гостьових публікацій – це місце, де технічні експерти діляться своїми знаннями та надають нейтральні, незацікавлені глибокі аналізи щодо ШІ, інфраструктури даних, кібербезпеки та інших передових технологій, що формують майбутнє підприємства.
Читайте більше з нашої програми гостьових публікацій — і ознайомтеся з нашими рекомендаціями, якщо ви зацікавлені у внесенні власної статті!
Як захиститися (Порада CryptoDom): З огляду на зміну ролі інженера від написання коду до прийняття рішень, критично важливо посилити навички аналізу та розуміння систем. Регулярно практикуйте глибоке рецензування коду (як свого, так і згенерованого ШІ), зосереджуючись на фундаментальних принципах роботи систем (мережі, бази даних, операційні системи), а не лише на логіці програми. Це допоможе виявляти приховані помилки, які можуть призвести до серйозних проблем у майбутньому.
За матеріалами: venturebeat.com