AI‑інструменти на кшталт Claude Code обіцяють будь‑кому — навіть без технічної освіти — можливість зібрати справжній продукт. Підприємець Остін Марчезе, який працює з неінженерними засновниками, демонструє це на практиці: разом із фаундером BDG Ніком, що не мав жодного досвіду програмування, він перебудував комерційний застосунок за 45 днів, поклавшись на Claude Code для кожної сторінки й кожної фічі.
Але за цією історією стоїть не магія, а чітка методика. Вона починається з радикально простого формулювання цінності продукту, продовжується розділенням «інженерної» та «піратської» роботи, переходить у навчання технічній лексиці замість коду і завершується побудовою AI‑процесів контролю якості. У центрі — питання: як змусити Claude Code працювати як надійний інженер, а не як хаотичний генератор коду.
Одна фраза без «і»: як змусити продукт сфокусуватися
Перший крок у стратегії Марчезе — не відкривати IDE, а відкрити текстовий редактор. Поки засновник не може описати застосунок одним реченням, продукт вважається надто розмитим.
Показовий приклад — застосунок для підрахунку калорій CaliAI. Його суть вкладається в одну фразу: «Зроби фото їжі й отримай калорії». У цьому формулюванні немає «і»: немає «і відстежуй макроси», «і плануй раціон», «і ділись з друзями». Дві прості дії, дві екрани — і зрозумілий сценарій використання.
Той самий принцип Марчезе застосовує до спільного з Ніком проєкту для фанатів фентезі‑футболу. Застосунок описується як продукт із двома ключовими цінностями: отримувати інформацію про фентезі‑футбол і грати у фентезі‑вікторини. Не 15 функцій, а дві, які логічно доповнюють одна одну.
Звідси випливає практичне правило: описуючи продукт, варто буквально викидати слово «і» з речення. Якщо без нього сенс розвалюється, значить, ціннісна пропозиція ще не сфокусована. Така дисципліна не лише спрощує маркетинг, а й задає чіткі рамки для Claude Code: модель отримує конкретну мету, а не розмитий список побажань.
Марчезе формулює це як боротьбу з абстракцією. Чим більше запитань користувач має поставити собі, відкриваючи застосунок, тим менша ймовірність, що він ним скористається. Просте речення без «і» — це фільтр проти зайвої складності ще до того, як з’явиться перший рядок коду.
Інженер проти пірата: де можна ламати, а де — ні
Коли цінність продукту визначена, наступне питання — як саме будувати. Марчезе пропонує мислити в двох режимах: «інженер» і «пірат».
Режим інженера — це все, де помилка коштує грошей або довіри. До цієї зони він відносить логін, платежі, роботу з користувацькими даними, архітектуру бази даних, інфраструктуру. Тут потрібні обережність, подвійна перевірка, повільні і свідомі зміни. У випадку з BDG саме ці частини Марчезе взяв на себе: автентифікація, платіжні інтеграції, бекенд‑інфраструктура. На кону були сотні тисяч доларів і досвід понад двох тисяч платних клієнтів — простору для експериментів тут немає.
Режим пірата — усе інше: контентні сторінки, екрани налаштувань, інтерфейс, нові фічі, кольори кнопок. Тут допустимо рухатися швидко, ламати, відкатувати, надсилати скріншоти в Claude Code зі словами «зроби ось так» і миттєво отримувати виправлення. Саме цю частину роботи в BDG вів Нік, використовуючи Claude Code як «вайб‑кодера» для швидкого прототипування й ітерацій.
Ключова ідея — не в тому, щоб розділити людей, а в тому, щоб розділити підходи. Одна й та сама людина може бути і інженером, і піратом, але вона має чітко розуміти, у якій зоні зараз працює. Там, де бізнес‑критичні потоки, — обережність і процеси. Там, де UI та експерименти, — швидкість і сміливість.
Щоб це розділення працювало й для AI‑асистента, Марчезе пропонує прямо навчити Claude Code відрізняти ці зони. Для цього він використовує файл Claude MD — свого роду технічну «пам’ять» про проєкт, яку модель отримує з кожним запитом. Спеціальний промпт оновлює цей файл, позначаючи критичні робочі потоки й додаючи інструкцію: попереджати перед будь‑якими змінами в цих ділянках.
Таким чином, Claude Code отримує карту мінного поля: де можна сміливо перекопувати код, а де кожна правка має проходити через додаткові перевірки. Це простий, але важливий крок, який перетворює модель з «генератора коду» на учасника інженерного процесу з базовим розумінням ризиків.
Вивчити слова, а не синтаксис: чому словник важливіший за курс з JavaScript
Найбільший бар’єр для неінженерних засновників, із якими працює Марчезе, — не відсутність уміння писати код, а відсутність технічного словника. Claude Code, як і інші моделі, навчений на масиві технічної документації, де все назване своїми іменами. Коли користувач використовує правильний термін, модель точно розуміє, що від неї хочуть. Коли ж ні — вона змушена здогадуватися.
Ця різниця стає критичною на технічно складних ділянках. Марчезе наводить конкретний приклад із фентезі‑застосунку: спільна драфт‑дошка, де кілька користувачів мають бачити дії одне одного в реальному часі.
Нетехнічний запит виглядає приблизно так: «Мені потрібно, щоб користувачі бачили дії одне одного миттєво, без перезавантаження сторінки». Claude Code, швидше за все, реалізує це через polling — періодичні запити до сервера у фоновому режимі. Формально це працює: сторінка не оновлюється, дані з’являються. Але кожні кілька секунд кожен підключений користувач звертається до бази даних. За тисячі одночасних сесій це перетворюється на тисячі зайвих запитів за хвилину, що може буквально «покласти» застосунок.
Модель зробила саме те, що її попросили. Проблема в тому, що користувач не знав, як правильно сформулювати запит. Якби в промпті з’явилося одне слово — «використай web sockets» — Claude Code побудував би зовсім іншу архітектуру: постійні двосторонні з’єднання без постійного опитування бази, без зайвого навантаження.
Цей приклад Марчезе називає уроком, отриманим «по‑жорсткому». І робить із нього висновок: неінженерам не потрібно сідати за підручник з програмування, але їм варто інвестувати час у базову технічну лексику. Ті ж «web sockets», «modal», «card», «toast notification», «happy path» і «unhappy path», «responsive design» — це не жаргон для посвячених, а інструменти точного спілкування з моделлю.
Щоб знизити поріг входу, Марчезе підготував промпт, який, за його словами, охоплює близько сорока ключових технічних термінів. Його можна вставити в Claude Code, і модель сформує пояснення цих понять у контексті конкретного проєкту. Це не замінює системної освіти, але дає засновнику мінімальний словник, достатній для того, щоб AI‑інструмент перестав «вгадувати» і почав виконувати завдання так, як задумано.
AI‑коуч і ритуали безпеки: як вбудувати контроль якості в Claude Code
Навіть із правильним словником і чітким поділом на «інженера» та «пірата» залишається питання: як не зламати все, коли продукт уже в руках реальних користувачів. Марчезе наполягає, що швидкість без обмежень неминуче призводить до поломок, і пропонує будувати навколо Claude Code власну систему «страхувальних тросів».
Перший рівень — планування перед написанням коду. Замість того щоб одразу просити модель «зроби мені сторінку налаштувань», він використовує інший підхід: просить Claude Code спочатку провести інтерв’ю. Модель має поставити серію запитань: яку проблему вирішує фіча, для кого вона, як виглядає успіх, чого вона не повинна робити. Лише після цього — підсумувати вимоги й отримати підтвердження від засновника.
Це виглядає як зайва бюрократія, але на практиці економить години. Без такого інтерв’ю модель часто будує «типову» сторінку, яка не відповідає очікуванням, і команда витрачає години на дрібні правки. Десять хвилин на чітке формулювання вимог проти десяти годин відлагодження — арифметика, яку Марчезе вважає очевидною, але яку більшість користувачів AI‑інструментів ігнорує.
Другий рівень — автоматизований код‑рев’ю. У BDG команда створила в Claude Code дві обов’язкові команди: code review і prepare to deploy. Перша аналізує зміни в коді, виявляє потенційні проблеми, друга перевіряє, чи все готово до продакшн‑деплою: чи немає помилок, чи узгоджені міграції з фактичною схемою бази, чи не торкнулися випадково чутливих зон на кшталт автентифікації або платежів.
Важливий момент: ці команди не є «рекомендаціями», які можна проігнорувати. Вони повертають чіткий вердикт — «готово» чи «не готово» — і список того, що потрібно виправити. І Марчезе, з восьмирічним досвідом розробки, і Нік, який працює в режимі «вайб‑кодингу», зобов’язані проганяти кожну фічу через ці перевірки перед деплоєм. За словами Марчезе, такий підхід неодноразово рятував застосунок від серйозних поломок ще до того, як їх помітили користувачі.
Третій рівень — зовнішній AI‑аудит. Щоб допомогти засновникам, які не впевнені в архітектурі свого проєкту, Марчезе створив безкоштовний плагін Claude Code на buildpartner.ai. Одна з його навичок — Claude coach — аналізує весь кодовий репозиторій і видає персоналізовані рекомендації: від технічних ризиків до слабких місць у ціннісній пропозиції продукту. Інша навичка, expert advice, оцінює саме value proposition, допомагаючи зрозуміти, чи не розмивається початкове «речення без “і”».
У сукупності це формує те, що Марчезе називає AI‑інженерним воркфлоу: модель не просто генерує код на вимогу, а бере участь у всіх етапах — від уточнення вимог до фінальної перевірки перед релізом.
Як не грати в «битву з багами»: повторне використання замість копіювання
Окрема проблема, про яку Марчезе говорить у продовженні своєї стратегії, — ефект «кривого дзеркала» в кодовій базі, коли одна й та сама логіка реалізована десятками різних способів у різних місцях. У традиційній розробці це відома хвороба, але з Claude Code вона посилюється: модель легко й швидко створює нові форми, компоненти й обробники, і спокуса «просто згенерувати ще одну» стає дуже великою.
Наслідок — класична гра в «whack‑a‑mole» із багами. Виправляючи помилку в одній формі, команда раптом виявляє, що така сама логіка реалізована ще в трьох місцях, але трохи інакше. Оновлення в одному компоненті не поширюється на інші, і кожна зміна перетворюється на ручний обхід десятків файлів.
Щоб уникнути цього, Марчезе радить будувати культуру повторного використання компонентів і прямо в промптах змушувати Claude Code шукати вже наявні рішення. Перед тим як просити модель створити нову форму чи модальне вікно, він пропонує ставити завдання інакше: спочатку знайти в кодовій базі подібний компонент, проаналізувати, чи можна його розширити або параметризувати, і лише якщо це неможливо — створювати новий.
Це просте правило різко знижує кількість дубльованого коду й робить застосунок більш передбачуваним. Один компонент — одна логіка, одне місце для виправлень. Для AI‑моделі це теж вигідно: маючи менше, але більш узагальнених будівельних блоків, Claude Code легше підтримувати цілісність проєкту.
Висновок: AI як інженер, а не чарівна паличка
Історія Марчезе з BDG показує, що Claude Code може стати повноцінним учасником розробки комерційних застосунків, але лише за умови, що людина на іншому кінці чату поводиться не як пасивний замовник, а як продюсер процесу.
Фокус на одній чіткій цінності без «і», розділення «інженерних» і «піратських» зон, навчання технічній лексиці замість синтаксису мов програмування, вбудовані AI‑процеси планування, рев’ю та деплою, а також дисципліна повторного використання компонентів — усе це перетворює хаотичне «вайб‑кодинг» на керований інженерний воркфлоу.
Для неінженерних засновників це означає, що поріг входу в розробку SaaS‑продуктів справді знизився. Але замість того, щоб витрачати місяці на курси з програмування, варто інвестувати час у розуміння власного продукту, базовий технічний словник і побудову процесів навколо Claude Code. Саме ці речі, а не чергова модель чи плагін, визначають, чи стане AI вашим головним інженером або головним джерелом багів.
Джерело
YouTube — How I Built a $481k App With Claude Code (Beginner Strategy)