Гаррі Тан, керівник одного з найвпливовіших акселераторів світу Y Combinator, публічно показав свій підхід до роботи з Claude Code — і він радикально відрізняється від звичного «напиши мені ось це». Автор каналу Austin Marchese розібрав його публічний плейбук і виділив чотири ключові стратегії, які дозволяють Танy запускати десятки фіч і внутрішніх сервісів, паралельно керуючи найбільшим стартап-акселератором.
1. «Віртуальна інженерна команда» замість одного асистента
Базова ідея — не ставитися до Claude як до універсального помічника, а будувати з нього команду з ролями, процесами та рев’ю. Для цього Тан створив систему Gstack, яку виклав у відкритий доступ на GitHub і описує як «віртуальну інженерну команду».
У цій моделі є:
- «CEO», який переосмислює продукт
- «Engineering manager», який фіксує архітектуру
- «Дизайнер», який відловлює «AI-slop» — неякісні, розмиті рішення
- Окремі ролі для безпеки, рев’ю коду тощо
Ключова технічна деталь — файл claude.md. Він автоматично додається до кожного запиту й задає сталі інструкції для системи. У ньому Тан використовує три принципи:
1. Skill routing (маршрутизація навичок)
Замість того, щоб щоразу вручну вказувати, який «агент» за що відповідає, користувач просто описує задачу. Система сама вирішує, яку роль підключити. Це працює як вбудований «проєктний менеджер» для Claude Code.
2. Пошук перед побудовою
Перед тим як писати новий код, Claude змушують шукати в існуючій базі. Це критично, коли проєкт росте: менше дублювання, менше «вигадування велосипеда».
3. «Компресія зусиль» (effort compression)
Не всі задачі потребують однакової глибини аналізу.
– дрібні зміни — швидка відповідь;
– нова фіча чи архітектурне рішення — глибоке опрацювання.
Ці три механізми зводяться до одного: дати моделі правильну роль, контекст і рівень зусиль — і не заважати. У результаті Gstack уже встиг показати практичну користь: один із CTO повідомив Танy, що «security»-роль у Gstack виявила вразливість, яку пропустила вся його інженерна команда. Його реакція: «Це як god mode».
2. Паралельні сесії: де закінчується продуктивність і починається хаос
Ще один елемент підходу Танa — робота з Claude Code «як CEO з командою». Він одночасно запускає багато сесій:
- одна збирає фічу,
- інша робить код-рев’ю,
- третя перевіряє безпеку,
- загалом — до 10+ паралельних робочих просторів.
Ідея — не мікроменеджити, а «чекінитися» лише по ключових рішеннях, дозволяючи решті процесів іти самостійно.
Однак саме тут починається суперечка. Попри заяву Танa, що «90% нових репозиторіїв з часом використовуватимуть Gstack», частина спільноти критикує підхід:
- дехто вважає, що він «перевинайшов те, що й так усі роблять»;
- інші називають результат «AI-slop» і сумніваються в реальній цінності.
Практична проблема очевидна: якщо намагатися керувати десятком агентів одночасно, легко почати «сліпо» затверджувати результати, забуваючи, хто що робить, і в підсумку отримати фрагментований, неякісний продукт.
Робочий компроміс, який пропонується:
не більше п’яти паралельних сесій Claude Code. Це дозволяє тримати кілька потоків роботи, але не розмазувати увагу до стану, коли контроль якості стає ілюзією.
3. Внутрішні інструменти як новий «дефолт»: будувати дешевше, ніж пояснювати
Найрадикальніша зміна, яку демонструє Тан, — це ставлення до ROI від розробки. Зі здешевленням створення софту за допомогою AI планка «чи варто це будувати» різко впала.
Тан наводить власні цифри:
- за 60 днів — 3 продакшн-сервіси,
- понад 40 випущених фіч,
- усе це — «part-time», паралельно з повноцінною роботою CEO YC.
Важливий нюанс: у нього є ресурси найняти десятки інженерів, але він свідомо обирає будувати інструменти сам із Claude Code. Логіка проста:
час, витрачений на пояснення задачі людині, часто дорожчий, ніж час на її реалізацію з AI.
Один із показових прикладів — G-Brain:
- система особистих знань, яка збирає зустрічі, емейли, твіти, події календаря;
- перетворює їх на «пошуковий мозок»;
- Claude (або інша модель) може читати цей «мозок» перед кожною відповіддю.
G-Brain — лише ілюстрація ширшого тренду:
кожен внутрішній тул, кожен робочий процес, який допомагає навіть одній людині, тепер, найімовірніше, вартий того, щоб його побудувати.
Звідси й висновок: перестати надмірно рахувати окупність дрібних інструментів і почати їх просто будувати. Бар’єр входу в розробку впав настільки, що «не будувати» стає новою розкішшю.
4. Планування перед кодом: «офісні години» як обов’язковий етап
Остання стратегія — та, яку підтримують практично всі сильні користувачі Claude Code: не писати код, поки немає чіткого плану.
Цього підходу дотримуються:
- Forest Tery, творець Claude Code;
- Андрій Карпати, який спершу структурує весь контекст, а вже потім запускає модель;
- сам Тан, який вбудував планування в Gstack.
У системі Танa це реалізовано через команду /office-hours. Перед тим, як буде написано хоч один рядок коду, запускається структуроване інтерв’ю:
- яку проблему вирішує продукт;
- для кого він;
- як виглядає успіх;
- чого продукт не повинен робити.
Фактично це формалізація того, як Тан працює зі стартапами на «офісних годинах» у YC, але перенесена в AI-процес. Модель не починає будувати, поки немає узгодженого бачення. За словами Танa, завдяки такій структурі він може:
- проводити 8–9 годин зустрічей на день,
- паралельно отримувати до 10 000 рядків коду
- одразу в кількох проєктах.
Ключова теза: саме планування робить основну частину роботи. Якщо його пропустити, AI просто дуже швидко поведе вас у неправильному напрямку.
Висновок: чотири принципи, які змінюють «норму» роботи з AI
Підхід Гаррі Тана до Claude Code можна звести до чотирьох практичних правил:
-
Давайте моделям ролі, а не розмиті задачі.
Сталі інструкції, маршрутизація навичок, пошук по коду й «компресія зусиль» перетворюють один інструмент на керовану «команду». -
Паралельте роботу, але не жертвуйте контролем.
Паралельні сесії корисні, але їхня кількість має відповідати вашій здатності реально перевіряти результат. -
Будуйте власні інструменти без зайвих сумнівів.
Вартість розробки впала настільки, що внутрішні тулзи для однієї людини часто окупаються автоматично. -
Плануйте перед тим, як писати код.
Структуроване «інтерв’ю» з самим собою через AI — фундамент, без якого решта стратегій дає лише ілюзію швидкості.
Для індустрії це сигнал: робота з AI виходить далеко за межі «попросити написати функцію». Мова вже про побудову повноцінних систем — із ролями, процесами, внутрішніми сервісами та чітким управлінням, де людина виступає не виконавцем, а архітектором.