Минулого тижня один із наших менеджерів з продуктів (PM) не просто спланував, а й реалізував нову функцію. Він не створював технічне завдання, не заводив тікет у системі керування проектами. Він фактично написав код, протестував його та впровадив у продакшн – усе за один день.
Кілька днів перед цим дизайнер помітив, що візуальне оформлення наших плагінів для IDE відхилилося від загальної дизайн-системи. У минулому це означало б створення скріншотів, оформлення тікету, довгі обговорення для пояснення намірів та виділення часу у спринті. Натомість він скористався інструментом на базі штучного інтелекту, самостійно змінив компоновку, експериментував, ітерував та налаштував у реальному часі, після чого одразу ж застосував виправлення. Людина з найглибшим розумінням дизайну безпосередньо втілила своє бачення. Жодного шару перекладу не знадобилося.
Теоретично, нічого з цього нового. Концепція “vibe coding” (кодування на інтуїтивному рівні) відкрила двері до створення програмного забезпечення для мільйонів. Це була лише обіцянка. Коли я ділився даними про те, як наші інженери подвоїли продуктивність, переключившись з написання коду на верифікацію, вивівши дизайн на передній план для швидкого експериментування, це все ще виглядало як суто інженерна історія. Те, що змінилося – це перехід від теорії до практики. Ось як це насправді відбувалося.
Вузьким місцем стала швидкість прийняття рішень
Коли у 2025 році ми перейшли на парадигму “AI-first”, вартість впровадження різко знизилася. Штучний інтелект взяв на себе завдання з побудови каркасу коду, створення тестів та написання рутинного “клеючого” коду, який раніше “з’їдав” половину спринту. Цикли розробки скоротилися з тижнів до днів, а згодом – до годин. Інженери почали думати менше про файли та функції, а більше про архітектуру, обмеження та плани виконання.
Проте, коли інженерні ресурси перестали бути вузьким місцем, ми помітили дещо інше: найповільнішим елементом системи стала швидкість прийняття рішень. Усі координаційні механізми, які ми розробили для захисту часу інженерів (специфікації, тікети, передача завдань, планування беклогу), тепер уповільнювали весь процес. Ми оптимізували систему під обмеження, яке вже не існувало.
Що відбувається, коли розробка стає дешевшою за координацію
Ми почали ставити собі інше запитання: як би це виглядало, якби люди, найближчі до вихідного задуму, могли безпосередньо втілювати програмне забезпечення?
Менеджери з продуктів вже мислять специфікаціями. Дизайнери визначають структуру, компоновку та поведінку. Вони не думають у термінах синтаксису. Вони думають у термінах результатів. Коли вартість перетворення ідеї на робоче програмне забезпечення достатньо знизилася, ці спеціалісти не потребували “вчитися програмувати”. Вартість впровадження просто опустилася до їхнього рівня.
Я попросив одного з наших PM, Дмитра, описати зміни з його точки зору. Він розповів: “Поки агенти генерують завдання в Zenflow, виникає кілька хвилин простою. Просто мертвий час. Мені захотілося створити маленьку гру, щось, чим можна зайнятися, поки чекаєш”.
Якщо ви коли-небудь керували командою продукту, ви знаєте, що це за ідеї. Вони не впливають на ключові показники ефективності (KPI). Їх неможливо обґрунтувати на зустрічах з пріоритезації. Вони відкладаються на невизначений термін. Але такі дрібниці додають індивідуальності. Вони роблять продукт таким, що відчувається, ніби хтось піклувався про дрібниці. Це саме ті речі, які оптимізуються з кожної сесії планування беклогу, і саме те, що запам’ятовують користувачі.
Він створив цю гру за один день.
Раніше така ідея загинула б у таблиці пріоритезації. Не тому, що вона була поганою, а тому, що вартість її впровадження робила її недоцільною. Коли ця вартість наближається до нуля, розрахунки кардинально змінюються.
Впровадження стало дешевшим за пояснення
Зі зростанням кількості людей, які почали створювати програмне забезпечення безпосередньо, цілі шари процесів тихо зникли. Менше тікетів. Менше передачі завдань. Менше розмов типу “чи не могли б ви пояснити, що ви мали на увазі…”. Менше моментів непорозуміння через втрату інформації.
Для значної частини завдань стало швидше просто створити щось, ніж описувати бажане та чекати, поки хтось інший це зробить. Замисліться над цим на мить. Кожна сучасна організація, що займається розробкою програмного забезпечення, побудована на припущенні, що впровадження є найдорожчою частиною процесу. Коли це припущення руйнується, організація мусить змінюватися разом із ним.
Випадок з нашим дизайнером, який виправляв UI плагіна, є ідеальним прикладом. Старий робочий процес (зробити скріншот проблеми, створити тікет, пояснити розрив між задумом та реалізацією, чекати на місце у спринті, переглянути результат, запросити коригування) існував виключно для оптимізації використання інженерних ресурсів. Коли людина з дизайнерською інтуїцією може діяти безпосередньо, весь цей стек зникає. Не тому, що ми усунули процес заради процесу, а тому, що процес вирішував проблему, якої вже не існувало.
Ефект накопичення
Ось що мене найбільше здивувало: це накопичується.
Коли PM самі створюють свої ідеї, їхні специфікації стають чіткішими, оскільки вони тепер розуміють, що потрібно агенту для ефективного виконання. Чіткіші специфікації дають кращий вихід від агента. Кращий вихід означає менше циклів ітерацій. Ми спостерігаємо, як продуктивність зростає тиждень за тижнем, не тільки завдяки покращенню моделей, але й тому, що люди, які їх використовують, наблизилися до самої роботи.
Дмитро влучно сформулював: цикл зворотного зв’язку між задумом та результатом скоротився з тижнів до хвилин. Коли ви можете миттєво бачити результат своєї специфікації, ви вчитеся, яка точність потрібна системі, і починаєте надавати її інстинктивно.
Існує другорядний ефект, який важче виміряти, але неможливо не помітити: відчуття причетності та відповідальності. Люди перестають чекати. Вони перестають створювати тікети для речей, які могли б виправити самі. “Розробник” перестав бути посадою. Це стала поведінка за замовчуванням.
Що це означає для індустрії
Значна частина наративу “код може писати кожен” минулого року була теоретичною або зосередженою на окремих засновниках та невеликих командах. Те, що ми пережили, відрізняється. У нас близько 50 інженерів працюють над складною, успадкованою кодовою базою: множинні інтерфейси та мови програмування, корпоративні інтеграції, вся вага реальної виробничої системи.
Я не думаю, що ми унікальні. Я думаю, що ми одні з перших. І з кожним новим поколінням моделей розрив між тими, хто може створювати програмне забезпечення, і тими, хто не може, скорочується швидше, ніж усвідомлюють більшість організацій. Кожна компанія, що займається розробкою програмного забезпечення, ось-ось виявить, що її менеджери з продуктів та дизайнери мають незадіяний потенціал для створення, обмежений не навичками, а вартістю впровадження. Оскільки ця вартість продовжує падати, організаційні наслідки будуть глибокими.
Ми починали з наміру прискорити розробку програмного забезпечення. Те, чим ми стаємо, — це дещо інше: компанія, де кожен може втілювати свої ідеї.
Ендрю Філев — засновник і генеральний директор Zencoder.
Прогноз ІТ-Блогу: Найближчим часом ми побачимо подальше розмивання традиційних ролей у розробці ПЗ, де менеджери продуктів та дизайнери будуть активно використовувати генеративний ШІ для самостійного впровадження функцій. Це призведе до появи нових інструментів, оптимізованих для таких “низькорівневих” творців, і поставить під сумнів традиційні структури команд розробки.
Подробиці можна знайти на сайті: venturebeat.com