🎯 Peter Steinberger

Steinberger прошёл через полный цикл: подключил MCP-серверы, наблюдал за поведением Claude несколько недель, затем удалил всё. Его центральное наблюдение:

Проблема не в самих MCP-серверах — технически они прекрасны. Проблема в том, что наличие инструмента меняет поведение Claude:

• Есть Playwright MCP → Claude запускает браузер вместо статического анализа HTML
• Есть GitHub MCP → Claude делает API-вызовы вместо чтения локальных файлов
• Есть Database MCP → Claude строит запросы вместо анализа схемы по миграциям

Для проекта PSPDFKit с тысячами файлов C++, Swift и TypeScript, скорость статического понимания кода критически важна. Каждый лишний roundtrip через внешний инструмент — это дополнительная задержка и непредсказуемость.

Единственное исключение: базовый filesystem MCP если абсолютно необходим для доступа к файлам вне рабочего каталога.

Вместо MCP-сервера для каждого инструмента — одна строка в CLAUDE.md описывает CLI-команду. Это радикально проще и прозрачнее:

# Инструменты

## База данных
`psql $DATABASE_URL -c "SELECT ..."` — прямые SQL-запросы без MCP

## Deploy
`vercel deploy --prod` — деплой в production напрямую

## GitHub
`gh pr create --title "fix: ..." --body "..."` — создание PRs через CLI
`gh issue list --label bug --state open` — просмотр issues

## Логи
`axiom query 'status >= 500' --start=-1h` — поиск ошибок за последний час

## Тесты
`npm test -- --filter=PDFAnnotation` — запуск конкретных тестов

Принцип предельно прост: Claude видит команду → выполняет через Bash → получает результат. Никаких дополнительных слоёв протокола. Никакой возможности для "творческого" использования инструмента не по назначению.

Дополнительные преимущества этого подхода:

• Прозрачность: команды видны в истории сессии, легко воспроизводятся вручную
• Портабельность: не требуют настройки на каждой машине
• Предсказуемость: Claude не может "изобрести" нестандартное использование инструмента
• Дебаггинг: если что-то пошло не так — видно точную команду которую запускал Claude

Git worktrees активно рекомендуются многими экспертами для параллельного выполнения задач. Steinberger пробовал этот подход и пришёл к другому выводу:

Для его workflow параллельность через worktrees создаёт больше проблем, чем решает:

• Слияние изменений из нескольких worktrees требует постоянных ментальных усилий
• Claude теряет контекст при переключении между рабочими деревьями
• Отладка и тестирование усложняются при нескольких активных состояниях кода
• SDK с нативными компонентами требует чистого, линейного состояния для компиляции

Альтернатива: строгая дисциплина на main ветке.

• Атомарные коммиты — каждый коммит = одно логическое изменение, всегда зелёные тесты
• Feature flags — незавершённый код живёт за флагом, не мешает основной разработке
• Частые коммиты — каждые 15-30 минут, не ждать "полной готовности"
• Ясный фокус — одна задача за раз, без переключения контекста

Это требует дисциплины от разработчика, но устраняет всю сложность многоветочной работы с AI-агентом.

Его расчёт:

При десятках задач в день, каждая из которых требует подтверждений, суммарная потеря времени составляет 1-2 часа. Это неприемлемо для быстрого SDK с тысячами файлов.

Его система бэкапов (macOS):

• Arq Backup — непрерывный бэкап в облако, снапшоты каждые несколько минут
• SuperDuper — полные клоны диска для восстановления системы
• git stash + частые коммиты — дополнительный слой защиты на уровне кода

При таком покрытии максимальная потеря работы — несколько минут. Это приемлемо если каждая задача экономит 10+ минут на permission prompts.

Аналоги для Windows: Backblaze Personal Backup, VSS-снапшоты, rsync с временными метками, или любая система непрерывного бэкапа с гранулярностью до нескольких минут.

Всё что Claude должен знать о проекте — только в CLAUDE.md. Никаких внешних spec-файлов, никаких ADR-документов, никаких wiki для повседневных задач.

Жёсткий лимит: менее 100 строк. Если файл растёт сверх этого предела — это сигнал проблемы. Либо правила слишком детальные (упрости архитектуру проекта), либо правил слишком много (оставь только самые важные).

Почему краткость важна: чем длиннее CLAUDE.md, тем меньше вероятность что конкретное правило будет весомо влиять на решения Claude. Короткий, точный файл = выше соблюдение каждого правила.

# PSPDFKit — Claude Instructions

## Project
Cross-platform PDF SDK: iOS (Swift), Android (Kotlin), Web (TypeScript).
Shared C++ core accessed via NDK/JNI bridges.

## Critical Rules
- Never modify Core/ without explicit permission
- All public APIs need unit + integration tests
- Objective-C interop: maintain backward compatibility
- No force unwraps in Swift except clearly documented exceptions

## Tools
`psql $DATABASE_URL -c "..."` — database queries
`gh pr create --title "..."` — GitHub PRs
`npm test -- --filter=Name` — run specific test suites

## Commits
Atomic, present tense: "Add PDF annotation layer"
Never: "fix stuff", "wip", "temp", "changes"

Обратите внимание: в этом файле нет архитектурных решений, исторических объяснений, или "почему мы сделали X". Только то, что Claude должен делать прямо сейчас.

За всеми конкретными практиками стоит единая философия: каждый дополнительный элемент системы добавляет трение. Steinberger буквально считает стоимость каждого слоя:

• Каждое лишнее слово в CLAUDE.md → трение восприятия → Claude медленнее и менее точно понимает главное
• Каждый MCP-сервер → дополнительный сетевой слой + точка отказа → замедление и непредсказуемость
• Каждый worktree → ментальный overhead при управлении → медленнее принятие решений
• Каждый permission prompt → прерывание потока → суммарно часы в неделю

// Хороший воркфлоу — минимальный стек:
Claude + CLAUDE.md + Bash (CLI-команды) + git commit

// Плохой воркфлоу — слишком много слоёв:
Claude + 8 MCP-серверов + worktrees + permission prompts
+ ADR-документы + spec-файлы + wiki + hooks + agents

Важный нюанс: этот подход работает именно потому что у него надёжные бэкапы. Убирая защитные слои, он не становится безрассудным — он перекладывает защиту в одно надёжное, простое место (непрерывный бэкап) вместо многих сложных, взаимодействующих слоёв.