Claude Code відкриває можливість «збудувати будь-що» — від особистих автоматизацій до повноцінних SaaS‑продуктів. Але в епоху, коли за ті самі ідеї одночасно беруться Anthropic, OpenAI та інші гіганти, неправильний вибір напряму легко перетворює будь-який проєкт на марнування часу. Підприємець і розробник контенту Остін Марчезе, спираючись на публічні поради CEO Y Combinator Гаррі Тана, пропонує три практичні правила, які варто пройти як чекліст перед стартом будь-якого проєкту з Claude Code.
Правило 1. Уникнути «ідея‑пастки» й не стати під AI‑каток
Перша помилка більшості AI‑ентузіастів — будувати «щось цікаве», не розуміючи ні користувача, ні ринку, ні того, як змінюється середовище під тиском прогресу моделей.
Хто насправді користувач?
Є дві принципово різні траєкторії:
- Шлях 1: ви — єдиний користувач.
Це внутрішній тул, автоматизація, навчальний сайд‑проєкт, який економить вам, скажімо, три години на тиждень.
У такому випадку: - не потрібен маркетинг і дистрибуція;
- не потрібен масштаб;
- не потрібен «піксель‑перфект» дизайн.
Оптимальна стратегія — будувати «потворно й швидко», максимально спрощуючи інтерфейс і фокусуючись лише на функції. Будь-яка зайва година на красу — це втрата часу.
- Шлях 2: ви хочете зовнішніх користувачів.
Тут усе навпаки: дистрибуція стає головною проблемою, а не код чи модель. Без чіткої відповіді: - хто саме ці люди;
- яку конкретну болючу проблему вони мають;
- чому вони мають перейти з поточного рішення на ваше,
— проєкт практично приречений.
Гаррі Тан наголошує на важливості жорсткого звуження задачі: продукт має бути «ідеально підходящим» для чітко окресленої групи користувачів, а не універсальним чат‑ботом «на всі випадки життя».
Не підбирати копійки перед AI‑катком
Друга частина «ідея‑пастки» — спроба напряму конкурувати з фронтирними AI‑лабораторіями.
Приклад: інструмент кібербезпеки для аудиту кодової бази. Ідея виглядає сильно: висока цінність, широкий ринок, зрозумілий сценарій використання. Але саме над цим працюють Anthropic, OpenAI та інші гравці з тисячами інженерів і доступом до найпотужніших моделей. Це класична ситуація «підняти копійку перед паровим катком» — шанси виграти таку гонку мінімальні.
Ключове запитання, яке варто поставити собі до старту:
Як зробити так, щоб із покращенням моделей мій продукт ставав ціннішим, а не зайвим?
Тобто будувати не заміну моделі, а шар навколо неї: інтерфейси, інтеграції, робочі процеси, специфічні сценарії, де важлива не «сирова» потужність AI, а контекст, UX, доменна експертиза.
Щоб не потрапити в «ідея‑пастку», варто пройти простий тест:
- Це тільки для мене?
Якщо ні — чи можу я назвати п’ять конкретних людей, які б користувалися цим уже сьогодні? - Чи це не перед AI‑катком?
Чи мій продукт стає ціннішим у міру прогресу моделей, а не замінюється ними?
Правило 2. Будувати там, де ви живете: сила «вертикалі Т»
Інтуїтивна порада «будуйте в тій сфері, де маєте досвід» залишається актуальною, але причина змінилася. У світі, де будь-хто може попросити AI «зробити лендинг» чи «написати Facebook‑рекламу», поверхневі навички втратили унікальність.
Цінність змістилася в іншу площину — оцінювання якості.
Evals як новий «моат»
У стартап‑лексиконі з’явився термін evals — систематична оцінка того, що є хорошим, а що поганим результатом роботи моделі. Це не про написання промптів, а про:
- розуміння, чому один лендинг конвертує, а інший — ні;
- відчуття, яка реклама «зайде» аудиторії, а яка спалить бюджет;
- знання, які відповіді AI є прийнятними в конкретному домені (медицина, право, освіта), а які — небезпечними чи марними.
Гаррі Тан називає саме evals «реальним моатом» — тим, що важко скопіювати. Моделі стають доступними всім, а от накопичене судження про те, що працює, а що ні, — ні.
T‑shape як мапа вашої стратегії
Корисна ментальна модель — літера T:
- Горизонталь — широкий, але поверхневий набір знань: базовий маркетинг, загальне розуміння продукту, уміння користуватися AI‑інструментами. Це рівень будь-якої людини, яка просто «промптить» моделі.
- Вертикаль — глибока експертиза в одній сфері: ви бачили десятки кейсів успіху й провалу, розумієте нюанси, можете пояснити різницю між «нормально» і «видатно».
Будувати варто саме у своїй вертикалі. Там, де:
- ви можете швидко відрізнити хороший AI‑результат від поганого;
- знаєте контекст користувачів;
- розумієте, які помилки є критичними, а які — прийнятними.
Це особливо актуально на тлі поточного ландшафту AI‑інструментів: майже половина (49,7%) з них зосереджена в одній категорії (масовий сегмент), тоді як:
- охорона здоров’я — близько 1%;
- юридична сфера — менше 1%;
- освіта — менше 2%.
Тобто половина ринку тиснеться в одному куті, тоді як інші домени майже порожні. Інженер із «десяткою» технічних скілів, але нульовою доменною експертизою, у вашій галузі програє людині, яка має «одиницю» в коді, але «десятку» в предметній області — саме ця «десятка» і є вертикаллю Т, на якій варто будувати.
Правило 3. Усі стали CEO: як керувати своєю AI‑командою
Третє правило стосується не того, що будувати, а як. У традиційній моделі людина «робить роботу»: пише код, верстає, тестує. В AI‑ера це дедалі частіше виявляється неправильним рівнем гри.
Нова роль — оркестратор, який:
- ставить задачі;
- задає контекст;
- перевіряє результат;
- налаштовує процеси.
Фактично — CEO власної віртуальної команди, де в ролі співробітників виступають Claude Code, спеціалізовані моделі та кастомні агенти.
Гаррі Тан відзначає, що сьогодні надзвичайно молоді команди можуть виростити бізнес до $10 млн річного доходу менш ніж за рік, маючи менше 10 людей у штаті. Решту роботи беруть на себе моделі й автоматизація. Але це працює лише тоді, коли засновники вміють керувати AI, а не просто «юзати» його.
Один із показових кейсів — нетехнічний фаундер, який, грамотно організувавши роботу з Claude Code, став продуктивнішим за власну команду інженерів і за півтора місяця вийшов на застосунок із річною виручкою понад $400 тис. Його перевага була не в коді, а в лідерстві над AI‑інструментами.
Шість щоденних практик AI‑лідера
Щоб працювати на «керівному» рівні, а не на рівні «виконавця промптів», варто вибудувати шість базових звичок.
1. Онбординг AI як нового співробітника
Починати роботу з Claude Code «з чистого аркуша» — неефективно. Натомість варто створити файл claude.md — свого роду онбординг‑документ, де зафіксовано:
- хто ви й чим займаєтеся;
- які цілі проєкту;
- які стандарти якості;
- які обмеження й табу.
Чим більше релевантного контексту отримує модель на старті, тим менше часу піде на виправлення й переписування.
2. План до першого промпту
Замість того, щоб одразу «кидати» завдання в модель, варто спочатку дати AI проінтерв’ювати вас:
- яку проблему має вирішити фіча;
- як виглядає успіх;
- чого продукт не має робити.
10 хвилин такого планування часто економлять години переробок. Claude може сам поставити правильні уточнювальні запитання — головне, дозволити йому це зробити.
3. «Права доступу» на рівні співробітника
У Claude Code є механіка дозволів, і постійне ручне підтвердження кожної дії швидко перетворюється на вузьке місце. Логіка має бути такою самою, як із живими співробітниками:
- для зворотних дій (які легко відмінити) — дати агентам більше свободи;
- для руйнівних операцій — вимагати явного підтвердження.
Завдання — знайти баланс між безпекою й автономністю, щоб не перетворюватися на «клікера дозволів».
4. Кабінет спеціалізованих експертів
Замість одного «універсального» агента варто вибудувати панель спеціалістів, кожен із яких натренований на своєму наборі матеріалів:
- агент із продажів — на вашому sales‑плейбуку;
- контент‑агент — на попередніх статтях, сценаріях, бренд‑гайді;
- фінансовий агент — на ваших моделях, звітах, політиках.
Як і в реальній компанії, команда вузьких експертів завжди сильніша за одного «генераліста».
5. Рев’ю як менеджер, а не як виконавець
Ефективний підхід — змусити AI генерувати обсяг, а людині залишити функцію відбору:
- замість «зроби мені один варіант» — «зроби 10, я оберу найкращий»;
- замість «зроби все end‑to‑end» — «зроби середину процесу, а я задам початок і кінець».
Це дозволяє зберегти людський контроль над критичними рішеннями, використовуючи AI як прискорювач, а не як «чорну скриньку».
6. Прибрати себе як вузьке місце
Claude Code має низку функцій, які дозволяють винести частину роботи в автономний режим:
- Hooks — тригери, що спрацьовують автоматично (наприклад, після кожної сесії логувати, що спрацювало, а що ні).
- Scheduled agents — агенти за розкладом, які можуть щодня чи щотижня виконувати рутинні задачі без вашої участі.
- Loops — циклічні процеси на вашому комп’ютері, які запускаються з потрібною періодичністю.
Чим менше ви — «обов’язковий учасник» кожної дрібної операції, тим ближче ваша роль до справжнього CEO, а не «супероператора AI».
Чотири запитання перед стартом будь-якого AI‑проєкту
Навіть маючи три правила, варто пропустити ідею через фінальний фільтр:
- Хто саме цим користуватиметься?
Я — особисто? Моя команда? Клієнти? Зовнішні користувачі?
Відповідь «усі, кому цікаво X» — не підходить. Потрібна конкретика. - Чи не стою я перед AI‑катком?
Чи не намагаюся я побудувати те саме, що вже роблять великі лабораторії? Чи мій продукт стає додатком до прогресу моделей, а не його жертвою? - Чи розумію я це в практиці, а не тільки в теорії?
Чи можу навести реальні приклади провалів і успіхів у цій сфері? Якщо ні — я ще не експерт, і, можливо, це не моя вертикаль Т. - Чи узгоджується це з рештою моєї роботи?
Чи підсилює проєкт те, що я вже роблю, чи тягне вбік? Ідеї, які не створюють ефекту компаундингу, часто не варті зусиль.
Висновок
Епоха Claude Code і подібних інструментів не стільки про те, хто краще кодує, скільки про те, хто краще обирає ідеї й керує моделями. Уникнути «ідея‑пастки», будувати у власній вертикалі Т та працювати на рівні CEO власної AI‑команди — три базові умови, без яких навіть найсильніші моделі не перетворяться на реальний продукт чи бізнес.
Джерело
YouTube: Don’t Start ANY Claude Code Project Until You Watch This