Навичка, яка переживе АІ
Я почав з простої тези: коли будуєш продукт з АІ, навички проджект-менеджменту важливіші за навички програмування. Код пише АІ — вузьке місце в тому, щоб знати, що будувати, в якому порядку і коли сказати "не зараз".
Потім я посперечався про це з Claude, і теза несподівано ставала дедалі сильнішою.
Перше заперечення: щоб рев'юїти архітектуру, все одно потрібне інженерне чуття. Моя відповідь — ні, потрібно задати правильні обмеження, і АІ сам перевірить свою роботу проти них. Навіть самі обмеження — це здебільшого каталог чужих граблів, а АІ прочитав більший каталог, ніж будь-хто з нас.
Друге заперечення: деякі рішення — односторонні двері. Погана архітектура на масштабі, міграції даних, зламані API. Але придивімось. Переписати архітектуру раніше коштувало років роботи команди — тепер це тижні ітерацій плюс тести. Міграція даних — відпрацьований патерн: expand-contract, подвійний запис, поступове перемикання. АІ виконає все, якщо задати обмеження ("нуль даунтайму, відкат на кожному кроці"). Навіть зламати публічний API — рутина: компанії постійно закривають старі версії, клієнти мігрують, життя триває. Технічно майже всі двері виявились двосторонніми.
Але ось що пережило суперечку. Кожні "односторонні двері", які перестали бути технічною проблемою, перетворились на бізнесову. Зламати API легко закодити і дорого собі дозволити — ціна платиться клієнтами й довірою, і залежить від твоєї позиції на ринку, а не від алгоритму міграції. Google може сказати "мігруйте до березня". Стартап із трьома enterprise-клієнтами — мабуть, ні.
Тож фінальна версія не "PM важливіший за програмування". Вона жорсткіша: АІ з'їдає шар за шаром. Писати код стало рев'юїти код. Рев'ю стало задаванням критеріїв. Задавання критеріїв стає тим, що АІ пропонує сам. Внизу лишається те, що не делегуєш навіть теоретично: вибір між "ламаємо сумісність зараз і втрачаємо X клієнтів" чи "тягнемо legacy і платимо Y завжди" — з неповною інформацією і твоїм підписом під наслідками.
Оце і є робота. Все, що вище — тимчасове.