Ви не пишете код — ви керуєте «ШІ-командою»

Більшість людей використовує Coding Agent так, ніби вони досі технічні ліди: архітектуру перевіряють особисто, код-рев’ю роблять порядково, жоден рядок від ШІ не потрапляє в коміт без огляду. Якість так справді тримається. Але ціна якась? Ви — найбільше вузьке місце всього конвеєра. Усі рішення чекають на вас, усі деталі проходять через вас, а продуктивність агента мертво прив’язана до вашої уваги та часу.

Інді-розробники, які реально заробляють, давно зробили ключовий перехід: з TL в EM. Простими словами: TL — це коли ви самі пильнуєте кожен рядок коду, EM — коли ви дивитеся лише на те, чи працює результат. TL питає «чи правильно написаний цей код», EM питає «чи пройшла функція приймання». Зміна здається дрібною, але фактично вона масштабує вашу продуктивність з «виробітку однієї людини» до «виробітку цілої команди».

Чому зараз можна відпустити контроль: моделі перейшли критичну точку

Відпускати контроль можна лише тоді, коли якість коду достатня. Ця умова вже виконана: за основними публічними бенчмарками, топові моделі пишуть код з точністю понад 80% і впевнено обходять попереднє покоління (конкретні таблиці та цифри в різних оцінках відрізняються — перевіряйте свіжі дані на Artificial Analysis та SWE-Bench самі, не вірте жодним переказам, включно з моїми).

Що це означає? Код від ШІ після мінімальної перевірки не дає серйозних відхилень, а гранична користь вашого порядкового рев’ю впала нижче рівня окупності. Залишатися TL — значить витрачати свій найдорожчий час на найдешевший контроль якості. Ринок не платить за вашу «невпевненість». Клієнт платить лише за зданий результат.

Шлях перший: «підтвердження плану + цільове управління» замість порядкового нагляду

Як це впровадити? Перший крок — змінити робочий процес. Коли зрозуміло, яку функцію треба зробити, спочатку пройдіть з агентом технічний план. План підтверджено — віддаєте агенту ціль разом із планом і дозволяєте виконувати: писати код, ганяти автотести, усе на ньому. Ваша єдина задача — після завершення прийняти саму функцію, а не рев’юїти деталі коду.

Ось готовий шаблон промпта для плану:

1
2
3
4

Мені потрібно зробити [опис функції].
Обмеження: [стек/платформа/обов'язкова сумісність].
Спочатку виведи технічний план: 1) розбиття на модулі; 2) потоки даних; 3) можливі підводні камені.
Код пиши лише після мого підтвердження плану. Після написання сам прожени тести і покажи результати запуску.

На етапі приймання якість тримає чек-лист — код відкривати не потрібно:

• Проганяєте основний сценарій вручну, головний шлях без помилок
• Перевіряєте по одному граничному випадку (порожній ввід, наддовгий ввід, без інтернету)
• Усі автотести, які додав агент, проходять
• Знайшли баг — не лізете в код самі, а описуєте симптом агенту: він відтворює, лагодить, додає тест, ви приймаєте ще раз

Суть цього підходу — перенести точку перевірки раніше. У режимі TL ви валідуєте на рівні коду, і це коштує шалено дорого. У режимі EM ви валідуєте на рівні функції: кілька кліків, один прогін, кілька хвилин. У всьому циклі ваш час йде лише на дві речі: чітко сформулювати, що робити, і підтвердити, що зроблено правильно.

Шлях другий: вибір технологій — від «що я вмію» до «що найкраще підходить»

Зміна ролі дає прихований бонус: вибір стека більше не обмежений вашими навичками. У логіці TL ви несвідомо берете знайомі технології, бо зможете полагодити, якщо щось зламається. У логіці EM ви просто обираєте те, що найкраще підходить проєкту, а решту віддаєте агенту.

Один інді-розробник описував такий шлях (за його дописом, незалежно не перевірено): роблячи застосунок для перекладу субтитрів, спочатку взяв Electron, бо знав фронтенд, але продуктивність не влаштовувала. Тоді перейшов на незнайомі йому Swift + AppKit — і з допомогою ШІ пройшов усе без проблем. Плануючи наступний кросплатформний продукт, першим кандидатом поставив Rust, якого ніколи не писав. Чи правдива ця історія — судіть самі, але логіка перевіряється: сьогодні ввечері візьміть незнайомий стек і нехай агент проведе вас через утиліту на 100 рядків. Подивіться, чи застрягнете. Коротше: межа ваших навичок більше не виправдання, стек обирається лише за оптимальністю.

Шлях третій: швидкість ітерацій як ровик від конкурентів — і трохи математики

Коли ця схема запрацює, термін здачі стискається з тижнів до днів. Клієнт вранці формулює потребу, після обіду вже бачить версію для приймання. Конкуренти оновлюють раз на тиждень — ви раз на день. На Prom.ua, Rozetka-продажах послуг, Upwork та Fiverr людей, які беруть замовлення на ШІ-розробку, чимало, але більшість досі на етапі «ШІ допомагає мені кодити». З EM-моделлю ви просто граєте в іншій лізі.

Концепції концепціями, а ось розрахунок (оцінки консервативні, підставте свої розцінки):

• Типове замовлення «невеликий інструмент/міні-застосунок», чек — $150
• Режим TL: одне замовлення з правками — 5 днів, на повному навантаженні 4 замовлення на місяць, дохід $600
• Режим EM: план + приймання займають 1,5 дня, поки агент працює, ви паралельно берете наступне замовлення; фактичне навантаження — 2 дні на замовлення, 8–10 замовлень на місяць, дохід $1200–1500
• Витрати: підписка на ШІ за максимумом ~$20/міс, частка доопрацювань після введення чек-листа — близько 10%, на кожне замовлення закладайте пів дня буфера

Тобто за той самий місяць різниця — понад $600, і в режимі EM вашим обмеженням стає кількість замовлень, а не швидкість рук. Напишіть на сторінці послуг «робоча версія за 48 годин» — це диференціація, яку конкуренти не скопіюють.

Єдине вузьке місце — ви самі, коли не знаєте, що робити

У цієї моделі є чесне обмеження: коли треба придумати нову велику версію чи напрямок продукту, людина знову стає вузьким місцем. Агент, яким би сильним він не був, виконує лише ті цілі, які ви чітко сформулювали. Не придумали, що робити, — він не видасть жодного корисного рядка.

Тож EM-модель ставить до людини вищі вимоги — не до технічної глибини, а до продуктового чуття. Доведеться витрачати час на дослідження: що клієнти шукають на Prom.ua та Amazon, на які болі скаржаться у постах на Pinterest і Lemon8, які інструменти залітають у TikTok. Увесь час, зекономлений на рев’ю коду, інвестуйте в «зрозуміти, що саме робити». Саме там у цій моделі місце людини.

Почніть сьогодні: три кроки до зміни ролі

Якщо ви ще не брали замовлень, не женіться одразу за подвоєнням продуктивності. Вхідна точка простіша: викладіть на Prom.ua або Fiverr оголошення «кастомні ШІ-інструменти» з ціною $30–50 і пройдіть перше замовлення за трьома кроками нижче — отримаєте робочий процес, який можна повторювати, і реальне відчуття цін.

Крок перший: візьміть будь-який маленький проєкт і забороніть собі відкривати файли з кодом. Тільки план, постановка цілі, функціональне приймання. Пройдіть повний EM-цикл і запишіть витрачений час — це ваші власні дані з перших рук, цінніші за будь-які чужі кейси. Крок другий: доведіть до автоматизму правило «баг — спочатку описати агенту для відтворення та виправлення», самі в код не стрибаєте. Крок третій: у наступному проєкті свідомо оберіть незнайомий, але найбільш підходящий стек і перевірте, чи проведе вас ШІ через нього.

Критична точка можливостей ШІ-кодування вже позаду, і виграш зміщується від «тих, хто вміє писати код зі ШІ» до «тих, хто вміє керувати ШІ-командою». Сьогодні ввечері візьміть один проєкт і проженіть EM-процес за шаблоном і чек-листом вище.