cto-road — запуск AI-first проекта с нуля

Материалы доклада «Реальность AI-first проекта на десятки тысяч часов с 0» (AI Growth Days 2026, Екатеринбург). Не советы, а действия: каждый пункт — что сделать, какими файлами и как понять, что готово. Всё взято из живого проекта и обезличено.

Состав:

• specs/ — процесс спецификаций: правила, шаблоны, машинная проверка, git-хук, памятки по ролям
• planning/ — скилл планирования: граф зависимостей задач, эпики, описания, синхронизация с трекером
• telemetry/ — телеметрия Claude Code на команду: коллектор, токены, установщик, письмо команде, дашборд, разбор промптов моделью, детектор секретов, грабли
• presentation-skill/ — скилл коммерческих презентаций, который ведут дизайнеры и менеджеры: пример инструкции с владельцем не из разработки

---

Чек-лист

1. Репозиторий контекста — до первой строчки кода

• Создайте отдельный git-репозиторий и назначьте владельца-аналитика:

  mkdir project-context && cd project-context && git init
  mkdir -p source-documents/{calls,answers,requirements} decisions specs
  

• Заведите правило: расшифровка созвона попадает в source-documents/calls/ в день созвона; ответы заказчика — в answers/; ТЗ — в requirements/, и каждая новая версия — вместе с ченджлогом «что поменялось и почему».

• Решения, отличные от ТЗ, фиксируйте отдельными файлами в decisions/ — иначе модель будет тянуть из базы противоречащие куски.

Готово, когда: любое требование прослеживается до источника — созвона, ответа или версии ТЗ; агент видит то же, что человек.

2. Процесс спек: критерии до кода

• Скопируйте specs/ из этого репозитория к себе: rules.md, check.py, guides/, _template/.

• Включите проверку перед коммитом:

  mkdir -p .githooks && cp specs/hooks/pre-commit .githooks/
  git config core.hooksPath .githooks
  

• Первую фичу заведите по шаблону: _template/feature.md → обзор фичи, _template/story/ → сквозная задача со spec.md, tests.md и tech/<отдел>.md.

• Держите правило первой остановки: пока критерии приёмки не отревьюены тестировщиком и техлидом — тех-спеки не пишутся.

• Проверьте руками, что валидатор работает: python3 specs/check.py — он должен ругаться на незаполненный шаблон, критерии без негативного сценария и формулировки вида «работает корректно».

Готово, когда: коммит с плохой спекой не проходит, а противоречия критериев ловятся на ревью, а не в коде.

3. Оценка — по своему архиву, не по интуиции

• Соберите архив прошлых оценок в одну папку: сметы, декомпозиции, итоговые часы. Нет архива оценок — выгрузите закрытые спринты за год.
• Дайте модели новое ТЗ и архив; просите три ближайших проекта-аналога и оценку по ним, с самопроверкой.
• Провалидируйте руками и помните главное: архив «доагентский» — модель оценит сверху, как делали руками. Это ваш запас, но не правда.

Готово, когда: оценка моделью бьётся с ручной валидацией, и вы понимаете, в какую сторону она врёт.

4. Граф зависимостей задач — до начала работы

• Поставьте скилл: скопируйте planning/task-management-skill/ в .claude/skills/ вашего проекта.
• Дайте модели требования релиза — она раскидает первый вариант задач; дальше тимлид переразбирает: добавляет, режет на этапы, перегруппировывает связи. Это несколько кругов, а не один проход.
• Связь ставьте только если задача физически не может начаться раньше другой; «обычно делаем после» — не зависимость. У каждой связи пишите причину.
• Пример результата — planning/example-graph.svg: 46 задач, 110 связей, 16 слоёв одного реального релиза.

Готово, когда: видно, какая задача держит половину релиза, — до того, как в неё кто-то упёрся.

5. Тесты до реализации

• Критерии приёмки — до кода (шаг 2 это уже даёт).
• Порядок в работе агента: сначала тест по критерию, потом реализация; написанный тест агент не меняет — не сходится, меняется реализация.
• Правило переведите из текста в хук или CI: текстовые правила агент соблюдает примерно в половине случаев, проверка с кодом возврата — всегда.

Готово, когда: «подогнать тест под реализацию» технически не проходит.

6. Телеметрия агентных сессий

• Разверните коллектор (self-hosted SigNoz + Caddy с TLS), закройте OTLP-порты на 127.0.0.1 и выдайте каждому персональный токен — шаги 1–3 в telemetry/README.md, конфиги в telemetry/server/. Атрибуцию по сотруднику ставьте на сервере по токену, а не по тому, что прислал клиент.
• Письмо команде — до включения: что собираете, зачем, кто имеет доступ, что промпты читает модель, а не руководитель, и что в оценку эффективности это не входит. Шаблон — telemetry/email-to-team.md.
• Раздайте одну команду установки — telemetry/install.sh / install.ps1 дописывают ~/.claude/settings.json; начинайте с settings-minimal.json. Команду шлите в HTML в <pre> — plain-text ломает Gmail.
• Заведите страницу «кто подключился» и ходите по ней пинговать; дашборд по людям — стоимость по родному cost_usd, кэш, агентность (запросы — telemetry/sql.md).
• Через три дня — первый разбор промптов моделью по рубрике telemetry/analysis/coach_prompt.md: типовые ошибки окажутся персональными, чините их разговором с конкретным человеком. Еженедельно — coach_digest.py.
• Включите детектор секретов в промптах (secret_scan.py) — первое, что покажет телеметрия, будет токен в чате.

Готово, когда: вы видите стоимость каждой сессии и знаете, кому из команды что мешает, — по данным, а не по ощущениям.

7. Люди: процесс вместо уговоров

• Не начинайте с обучения — поставьте процесс, в котором без агента неудобно (шаги 1–5), на все проекты сразу.
• К буксующим отправляйте сильных на пару часов — чаще всего человек просто не понимает, как.
• У каждой инструкции — владелец, и он не обязательно разработчик: скиллы лежат в git, правит их тот, кто ими живёт. Пример — presentation-skill/: скилл коммерческих презентаций, который ведут дизайнеры и менеджеры; ставится и через приложение Claude без терминала.

Готово, когда: скептик становится сторонником после проекта, который иначе было не сделать, — а не после встречи.

8. Стык с заказчиком

• Согласуйте крупное, детализацию берите на себя — письменно.
• Вместо документа на сорок страниц — демо, которое можно потыкать.
• Доступы просите пошаговой инструкцией «куда зайти, что нажать», сгенерированной агентом.
• Мерьте дни от вопроса до решения — в обе стороны.

Готово, когда: срок проекта упирается в решения, а не в разработку, — и это видно по числам.