Так поэтому все и расписал подробно. А то везде слышу только “установи playwright MCP одним промтом и все будет работать”. Ну так-то да, будет, только вот, чтобы хорошо работало и стабильно придется потанцевать с бубном, даже используя нейронки.
Спасибо! PR не отправил намеренно: хотел сначала зафиксировать баг как есть, чтобы мейнтейнеры сами решили, какой фикс им ближе :) Там есть несколько вариантов: с одной стороны, можно переписать на while-цикл с корректным сдвигом. А с другой, например, можно взять каноническую реализацию Rytter (1980) или вообще заменить на Horspool, который проще и на практике не медленнее. Если issue не закроют в ближайшее время, отправлю PR с Horspool-вариантом.
Полностью согласен про “читать что пишут”. У нас на платформе (10 000+ университетов, 4M+ пользователей в год) мы активно используем Claude для автоматизации: классификация писем, генерация контента, парсинг данных. Ключевое отличие продуктивного использования от вайб-кодинга: ты всегда читаешь и проверяешь результат, понимаешь, почему модель предложила именно это решение, и знаешь, где она может ошибиться. Инструмент усиливает компетенцию, а не заменяет её. Человек без понимания домена получит от ИИ красивый, но нерабочий результат.
Использую Claude Code как основной инструмент разработки уже четвёртый месяц. EdTech-платформа, 10 000+ университетов в базе, 4M+ пользователей в год. Один разработчик.
Проблема не в вайб-кодинге как таковом. Проблема в том, что люди путают «умение пользоваться инструментом» с «пониманием того, что инструмент делает». Когда я прошу Claude написать парсер бинарного формата S-57, я знаю, что такое ISO 8211 и как устроены record headers. Когда результат неправильный, я могу объяснить почему и дать точную обратную связь.
Вайб-кодер в такой ситуации просто нажмёт «regenerate» пять раз и выберет вариант, который не падает. Разница не в инструменте, а в том, может ли человек прочитать то, что получил.
На собеседованиях это проверяется элементарно: покажите кандидату чужой код (можно AI-сгенерированный) и спросите «что здесь не так?». Если не может ответить без запуска, это и есть ваш ответ.
Интересный разбор про вторичную выгоду и «честные» оценки. Добавлю наблюдение из своей практики.
У меня 5 платформ для публикаций (LinkedIn, Facebook, X, Reddit, Habr) с ежедневным расписанием. Классический GTD: задачи в календаре, делай по списку. Но я не делал. Каждый день находились причины отложить.
Что сработало: я делегировал выполнение AI-агенту (Claude Code). Агент читает файл с расписанием, проверяет что уже сделано, и выполняет публикации автоматически. Моя задача сократилась до одной: написать контент и положить в файл.
Парадокс: автоматизация убрала вторичную выгоду откладывания. Когда задачу выполняет агент, нет эмоциональной нагрузки от «надо сесть и сделать». Нет и повода откладывать.
Это не решает проблему для задач, которые требуют творчества. Но для рутинных повторяющихся действий, автоматизация через AI оказалась лучшим GTD-инструментом, чем любой трекер.
Пришёл к похожим выводам, но с другой стороны: не дневник, а рабочая память для AI-агента.
У меня Claude Code управляет публикациями на 5 платформах. Между сессиями контекст теряется полностью. Решение: файл CHECKPOINT.md в корне проекта. Там статус каждой задачи, что уже сделано (DO_NOT_REDO), что проверить перед действием (VERIFY_BEFORE_ACT).
Ключевой момент, который совпадает с вашим наблюдением: структура памяти важнее объёма. Когда я писал память свободным текстом, агент терял контекст через 2-3 сессии. Когда перешёл на чёткие секции с метками статуса, стало работать стабильно.
Формула: память = структурированный файл + правило “прочитай перед любым действием”. Модель вторична.
Практика из продакшена: 100+ сессий Claude Code в день на нескольких проектах.
API (через Claude Code CLI) выигрывает, когда нужна автоматизация: cron-задачи, пакетная обработка, CI/CD пайплайны. У меня 107 Telegram-топиков, каждый маршрутизирует задачи отдельной сессии Claude с собственным контекстом. Это невозможно через Code-подписку.
Подписка выигрывает для интерактивной разработки: когда сидишь перед экраном и итеративно отлаживаешь. Артефакты, предпросмотр, файловый менеджер.
Ключевое наблюдение: стоимость API непредсказуема. Один неудачный промпт с большим контекстом может стоить больше, чем дневной лимит подписки. Для команд без опыта оптимизации промптов подписка безопаснее.
Практический опыт: 100+ сессий Claude Code в день, файловая память.
Использую ровно тот подход, который описан в статье как “три файла”. CLAUDE.md хранит неизменяемые правила проекта (паттерны кода, ограничения безопасности, стиль). CHECKPOINT.md хранит текущее состояние: последнее действие, следующий шаг, и список DO_NOT_REDO, чтобы после compaction агент не переделывал уже выполненную работу.
Третий файл — topic-memory.md, по одному на рабочий поток. Каждый Telegram-топик (использую как диспетчер проектов) получает свою память с целями, блокерами и платформенными заметками.
Почему файлы, а не БД: git diff показывает, что именно изменилось в памяти между сессиями. Это бесценно для отладки, когда агент начинает вести себя странно. С базой данных такой прозрачности нет.
Главный инсайт после полугода: самое важное в памяти агента — не что он помнит, а что он НЕ должен переделывать. Секция DO_NOT_REDO экономит больше токенов и времени, чем все остальные оптимизации вместе взятые.
Интересная тема. У нас в StudyQA (EdTech, 4M+ пользователей/год) прошли похожий путь, но без enterprise-уровня ресурсов — полезно было сверить опыт.
Что оказалось важнее всего:
Stateful контекст на уровне домена. Для нас это Telegram-топик на каждый тип задачи (контент, поддержка, аналитика). Без изоляции контекста модель смешивает домены и деградирует по качеству за несколько сессий.
Fallback-цепочка важнее retry. Недетерминированность на продакшне лечится не “попробовать снова”, а упрощённым промптом с меньшей степенью свободы. В критичных задачах: validate → retry с simplified prompt → escalate to human.
Observability трека агента, не только финального ответа. Мы начали с логирования только выхода, но отладка без промежуточных шагов — слепое угадывание. Сейчас пишем весь цикл: промпт, вызов, результат, применённое действие.
Из опыта: для mid-size команды самое ценное в enterprise-подходах — не сами паттерны, а понимание, где именно недетерминированность становится операционным риском. В контентных задачах терпимо. В финансовых и compliance — нет, и это надо закладывать в архитектуру с самого начала.
Узнаю ситуацию. Я управляю EdTech-платформой (StudyQA, 4 млн пользователей в год) фактически в одиночку — и в какой-то момент просто перестал ждать подрядчиков.
Что изменилось за последний год: я описываю задачу Claude, получаю архитектуру и первый рабочий код, тестирую на реальных данных, даю обратную связь. Недавно написал парсер морских карт формата S-57 (бинарный ISO 8211, сложный формат) за выходные. До этого — телесуфлёр для Android, опубликован в Google Play.
Узкое место сейчас не «умею ли я кодировать», а «умею ли я чётко объяснить задачу». Качество выхода напрямую зависит от качества постановки.
Один момент, который вы, скорее всего, уже поняли: AI не заменяет понимание продукта. Он усиливает его. Если вы знаете, что должно работать, — он поможет это построить.
Ответил вам в личные сообщения: платежи и доступы работают корректно. Если что-то недоступно, пришлите, пожалуйста, скриншоты оплаты и то, что вы видите на сайте.
Хороший обзор Cursor, но справедливости ради стоит упомянуть альтернативу: Claude Code (CLI) покрывает большинство описанных сценариев без привязки к IDE.
Я перешёл с Cursor на Claude Code примерно полгода назад. Ключевые отличия из моего опыта:
CLAUDE.md = .cursorrules на стероидах. Тот же принцип (правила проекта в файле), но Claude Code автоматически подхватывает иерархию: глобальный ~/.claude/CLAUDE.md + проектный CLAUDE.md. Не нужно руками указывать контекст.
Параллельность. В Cursor один агент на окно. Claude Code позволяет запускать десятки параллельных сессий на одном проекте через субагентов. У меня в продакшене ~100 параллельных сессий на разных проектах.
CLI вместо GUI. Звучит как минус, но на практике это плюс: можно автоматизировать через cron, запускать на VPS, интегрировать в пайплайны. Cursor привязан к десктопу.
MCP работает в обоих. Тут паритет. Но в Claude Code MCP-серверы доступны из коробки через конфиг, без UI.
Cursor лучше для визуального кодинга с автодополнением. Claude Code лучше для автоматизации и headless-сценариев. Оба инструмента хороши, выбор зависит от задачи.
Узнаю свой подход, только у нас реализация другая.
Мы пришли к похожей архитектуре, но вместо Go-бота с MCP-серверами используем Telegram-топики как естественный диспетчер. Каждый топик = один проект = одна изолированная сессия Claude Code. Роутер определяет, какую модель подключить (Opus для сложного, Haiku для рутины), и каждая сессия видит только свой рабочий каталог.
Несколько наблюдений из опыта с ~100 параллельными сессиями:
CLAUDE.md >> промпт-инструкции в агенте. У нас в каждом проекте CLAUDE.md с архитектурой, правилами безопасности и деплой-инструкциями. Работает надёжнее, чем передача контекста между агентами, потому что файл всегда актуален и не теряется при компакции.
CHECKPOINT.md как замена передачи состояния. Вместо водопада контекста между саб-агентами, каждая сессия пишет своё состояние в чекпоинт. При перезапуске или смене контекста читает один файл вместо перечитывания всего проекта.
Код-ревью человеком: полностью согласен. Это единственное, что реально отделяет рабочий пайплайн от “лотереи”. У нас деструктивные операции (деплой, удаление, push) требуют явного подтверждения.
Интересно, что вы Claude Code гоняете на VPS. Мы тоже: Hetzner VPS + Windows + Telegram Router. Фоновые задачи действительно удобнее на сервере, чем на локальной машине.
Хорошая статья с реальными цифрами, а не абстрактными “повысили продуктивность на 300%”.
Могу добавить свои данные. У меня EdTech-платформа с 4M+ пользователей в год, и я перешёл на AI-assisted разработку примерно год назад. Ключевые наблюдения:
Экономия на рутине реальная, но не там, где ожидаешь. Максимальный эффект не от генерации кода, а от автоматизации операционки: контент-пайплайны, мониторинг, деплой-скрипты, парсинг документов. То, что раньше делал ассистент или джун, теперь делает агент.
Claude Code + грамотный CLAUDE.md в каждом проекте дал примерно 3-4x по скорости на типовых задачах. Но на сложной бизнес-логике может быть 1.5x или даже медленнее, потому что приходится проверять и переделывать.
Самое неочевидное: экономия пришла не от замены людей, а от того, что я как CTO перестал быть бутылочным горлышком. Раньше 10 задач в очереди, я один. Сейчас 100+ параллельных сессий Claude Code на разных проектах, каждая в своём изолированном контексте.
Про ваш расчёт 400K на ERP: с AI-assisted я бы оценил 250-300K, но не 150K. Потому что тестирование и интеграции (банки, 1С) всё равно ручная работа. ИИ не заменяет понимание бизнес-процесса заказчика.
Хороший хак. Мы тоже столкнулись с этой проблемой, когда стали гонять ~100 сессий Claude Code в день по разным проектам — контекст забивался чтениями файлов моментально.
Ещё один паттерн, который хорошо работает в дополнение: CHECKPOINT.md в корне проекта. Каждая сессия при завершении пишет туда своё состояние (что сделала, что дальше, какие файлы трогала). Когда контекст компактится или сессия перезапускается — Claude читает один файл вместо того, чтобы заново сканировать полпроекта.
По сути это тот же принцип — держать контекст чистым. Только Read(1-1) экономит на уровне отдельных правок, а чекпоинт-файл — на уровне всей сессии.
А code-index — это свой MCP-сервер для индексации? Или что-то другое?
Ага, конфирмейшн флоу закрывает вектор “выполни деструктивное действие”, но не “подмени контекст диагностики”. У меня было так: сервис писал в Event Log строку с текстом, похожим на имя другого сервиса. Claude начинал копать не в ту сторону. Пользователь видит связную гипотезу, проверяет её 20 минут, а проблема в другом месте.
Что помогает частично: санитизация логов перед передачей в контекст (strip unicode control chars, обрезка строк длиннее 500 символов) и structured output, когда модель обязана указать источник каждого факта. Если в выводе написано “согласно Event ID 7034 от svchost”, это можно верифицировать автоматически.
Понятно, что это не решает проблему полностью, но сужает окно атаки до случаев, когда инъекция мимикрирует под валидный лог. А так да, согласен, что в тестах это ловится только через adversarial-сценарии с заведомо отравленными логами.
Cookie подписан HMAC (SHA-256). Старый aa_uid с голым Telegram ID заменен на aa_session с подписью: user_id:expiry:hmac. Флаги HttpOnly, Secure, SameSite=Lax. Подделать без серверного секрета не получится.
Видео и субтитры убрал из публичной директории. Файлы перенесены за пределы webroot, раздаются только через PHP-гейт с проверкой подписанной сессии. Для платных уроков дополнительно проверяется оплата. Range-запросы для перемотки поддерживаются.
Секреты вынесены из исходников. Пароли Robokassa и ключи авторизации больше не в коде, лежат в файлах за пределами git.
paid-check.php оставил как есть , он и не должен быть барьером, только UX, как вы и написали.
По поводу HTTP/2: если речь про Rapid Reset (CVE-2023-44487), это на стороне хостинга, тем не менее тоже переделал.
Подтверждаю из практики. Оркестрирую Claude Code через CLAUDE.md + system prompt, и самый большой прирост качества дал именно “контракт результата”, не промпт-инженерия.
Конкретный пример: промпт на генерацию постов для Telegram-канала. Было 1800 токенов с role-play, few-shot на 7 примеров и цепочкой CoT. Результат: модель копировала стиль примеров вместо обобщения.
Переписал в 200 токенов: жесткие ограничения (длина 800-1200 символов, максимум 1 эмодзи, конкретная структура), один пример формата, функциональная роль (“контент-редактор канала”). Качество выросло, а главное, стало стабильным.
Добавлю к выводам автора: с reasoning-моделями критично не только что писать в промпте, но и что убрать. Каждый лишний constraint модель честно пытается соблюсти, даже если он противоречит другим.
Подтверждаю из практики. Оркестрирую Claude Code через CLAUDE.md + system prompt, и самый большой прирост качества дал именно "контракт результата", не промпт-инженерия.
Конкретный пример: промпт на генерацию постов для Telegram-канала. Было 1800 токенов с role-play, few-shot на 7 примеров и цепочкой CoT. Результат: модель копировала стиль примеров вместо обобщения.
Переписал в 200 токенов: жесткие ограничения (длина 800-1200 символов, максимум 1 эмодзи, конкретная структура), один пример формата, функциональная роль ("контент-редактор канала"). Качество выросло, а главное, стало стабильным.
Добавлю к выводам автора: с reasoning-моделями критично не только что писать в промпте, но и что убрать. Каждый лишний constraint модель честно пытается соблюсти, даже если он противоречит другим.
Так поэтому все и расписал подробно. А то везде слышу только “установи playwright MCP одним промтом и все будет работать”. Ну так-то да, будет, только вот, чтобы хорошо работало и стабильно придется потанцевать с бубном, даже используя нейронки.
Спасибо! PR не отправил намеренно: хотел сначала зафиксировать баг как есть, чтобы мейнтейнеры сами решили, какой фикс им ближе :) Там есть несколько вариантов: с одной стороны, можно переписать на while-цикл с корректным сдвигом. А с другой, например, можно взять каноническую реализацию Rytter (1980) или вообще заменить на Horspool, который проще и на практике не медленнее. Если issue не закроют в ближайшее время, отправлю PR с Horspool-вариантом.
Полностью согласен про “читать что пишут”. У нас на платформе (10 000+ университетов, 4M+ пользователей в год) мы активно используем Claude для автоматизации: классификация писем, генерация контента, парсинг данных. Ключевое отличие продуктивного использования от вайб-кодинга: ты всегда читаешь и проверяешь результат, понимаешь, почему модель предложила именно это решение, и знаешь, где она может ошибиться. Инструмент усиливает компетенцию, а не заменяет её. Человек без понимания домена получит от ИИ красивый, но нерабочий результат.
Использую Claude Code как основной инструмент разработки уже четвёртый месяц. EdTech-платформа, 10 000+ университетов в базе, 4M+ пользователей в год. Один разработчик.
Проблема не в вайб-кодинге как таковом. Проблема в том, что люди путают «умение пользоваться инструментом» с «пониманием того, что инструмент делает». Когда я прошу Claude написать парсер бинарного формата S-57, я знаю, что такое ISO 8211 и как устроены record headers. Когда результат неправильный, я могу объяснить почему и дать точную обратную связь.
Вайб-кодер в такой ситуации просто нажмёт «regenerate» пять раз и выберет вариант, который не падает. Разница не в инструменте, а в том, может ли человек прочитать то, что получил.
На собеседованиях это проверяется элементарно: покажите кандидату чужой код (можно AI-сгенерированный) и спросите «что здесь не так?». Если не может ответить без запуска, это и есть ваш ответ.
Интересный разбор про вторичную выгоду и «честные» оценки. Добавлю наблюдение из своей практики.
У меня 5 платформ для публикаций (LinkedIn, Facebook, X, Reddit, Habr) с ежедневным расписанием. Классический GTD: задачи в календаре, делай по списку. Но я не делал. Каждый день находились причины отложить.
Что сработало: я делегировал выполнение AI-агенту (Claude Code). Агент читает файл с расписанием, проверяет что уже сделано, и выполняет публикации автоматически. Моя задача сократилась до одной: написать контент и положить в файл.
Парадокс: автоматизация убрала вторичную выгоду откладывания. Когда задачу выполняет агент, нет эмоциональной нагрузки от «надо сесть и сделать». Нет и повода откладывать.
Это не решает проблему для задач, которые требуют творчества. Но для рутинных повторяющихся действий, автоматизация через AI оказалась лучшим GTD-инструментом, чем любой трекер.
Пришёл к похожим выводам, но с другой стороны: не дневник, а рабочая память для AI-агента.
У меня Claude Code управляет публикациями на 5 платформах. Между сессиями контекст теряется полностью. Решение: файл CHECKPOINT.md в корне проекта. Там статус каждой задачи, что уже сделано (DO_NOT_REDO), что проверить перед действием (VERIFY_BEFORE_ACT).
Ключевой момент, который совпадает с вашим наблюдением: структура памяти важнее объёма. Когда я писал память свободным текстом, агент терял контекст через 2-3 сессии. Когда перешёл на чёткие секции с метками статуса, стало работать стабильно.
Формула: память = структурированный файл + правило “прочитай перед любым действием”. Модель вторична.
Практика из продакшена: 100+ сессий Claude Code в день на нескольких проектах.
API (через Claude Code CLI) выигрывает, когда нужна автоматизация: cron-задачи, пакетная обработка, CI/CD пайплайны. У меня 107 Telegram-топиков, каждый маршрутизирует задачи отдельной сессии Claude с собственным контекстом. Это невозможно через Code-подписку.
Подписка выигрывает для интерактивной разработки: когда сидишь перед экраном и итеративно отлаживаешь. Артефакты, предпросмотр, файловый менеджер.
Ключевое наблюдение: стоимость API непредсказуема. Один неудачный промпт с большим контекстом может стоить больше, чем дневной лимит подписки. Для команд без опыта оптимизации промптов подписка безопаснее.
Практический опыт: 100+ сессий Claude Code в день, файловая память.
Использую ровно тот подход, который описан в статье как “три файла”. CLAUDE.md хранит неизменяемые правила проекта (паттерны кода, ограничения безопасности, стиль). CHECKPOINT.md хранит текущее состояние: последнее действие, следующий шаг, и список DO_NOT_REDO, чтобы после compaction агент не переделывал уже выполненную работу.
Третий файл — topic-memory.md, по одному на рабочий поток. Каждый Telegram-топик (использую как диспетчер проектов) получает свою память с целями, блокерами и платформенными заметками.
Почему файлы, а не БД: git diff показывает, что именно изменилось в памяти между сессиями. Это бесценно для отладки, когда агент начинает вести себя странно. С базой данных такой прозрачности нет.
Главный инсайт после полугода: самое важное в памяти агента — не что он помнит, а что он НЕ должен переделывать. Секция DO_NOT_REDO экономит больше токенов и времени, чем все остальные оптимизации вместе взятые.
Интересная тема. У нас в StudyQA (EdTech, 4M+ пользователей/год) прошли похожий путь, но без enterprise-уровня ресурсов — полезно было сверить опыт.
Что оказалось важнее всего:
Stateful контекст на уровне домена. Для нас это Telegram-топик на каждый тип задачи (контент, поддержка, аналитика). Без изоляции контекста модель смешивает домены и деградирует по качеству за несколько сессий.
Fallback-цепочка важнее retry. Недетерминированность на продакшне лечится не “попробовать снова”, а упрощённым промптом с меньшей степенью свободы. В критичных задачах: validate → retry с simplified prompt → escalate to human.
Observability трека агента, не только финального ответа. Мы начали с логирования только выхода, но отладка без промежуточных шагов — слепое угадывание. Сейчас пишем весь цикл: промпт, вызов, результат, применённое действие.
Из опыта: для mid-size команды самое ценное в enterprise-подходах — не сами паттерны, а понимание, где именно недетерминированность становится операционным риском. В контентных задачах терпимо. В финансовых и compliance — нет, и это надо закладывать в архитектуру с самого начала.
Узнаю ситуацию. Я управляю EdTech-платформой (StudyQA, 4 млн пользователей в год) фактически в одиночку — и в какой-то момент просто перестал ждать подрядчиков.
Что изменилось за последний год: я описываю задачу Claude, получаю архитектуру и первый рабочий код, тестирую на реальных данных, даю обратную связь. Недавно написал парсер морских карт формата S-57 (бинарный ISO 8211, сложный формат) за выходные. До этого — телесуфлёр для Android, опубликован в Google Play.
Узкое место сейчас не «умею ли я кодировать», а «умею ли я чётко объяснить задачу». Качество выхода напрямую зависит от качества постановки.
Один момент, который вы, скорее всего, уже поняли: AI не заменяет понимание продукта. Он усиливает его. Если вы знаете, что должно работать, — он поможет это построить.
Ответил вам в личные сообщения: платежи и доступы работают корректно. Если что-то недоступно, пришлите, пожалуйста, скриншоты оплаты и то, что вы видите на сайте.
Хороший обзор Cursor, но справедливости ради стоит упомянуть альтернативу: Claude Code (CLI) покрывает большинство описанных сценариев без привязки к IDE.
Я перешёл с Cursor на Claude Code примерно полгода назад. Ключевые отличия из моего опыта:
CLAUDE.md = .cursorrules на стероидах. Тот же принцип (правила проекта в файле), но Claude Code автоматически подхватывает иерархию: глобальный ~/.claude/CLAUDE.md + проектный CLAUDE.md. Не нужно руками указывать контекст.
Параллельность. В Cursor один агент на окно. Claude Code позволяет запускать десятки параллельных сессий на одном проекте через субагентов. У меня в продакшене ~100 параллельных сессий на разных проектах.
CLI вместо GUI. Звучит как минус, но на практике это плюс: можно автоматизировать через cron, запускать на VPS, интегрировать в пайплайны. Cursor привязан к десктопу.
MCP работает в обоих. Тут паритет. Но в Claude Code MCP-серверы доступны из коробки через конфиг, без UI.
Cursor лучше для визуального кодинга с автодополнением. Claude Code лучше для автоматизации и headless-сценариев. Оба инструмента хороши, выбор зависит от задачи.
Узнаю свой подход, только у нас реализация другая.
Мы пришли к похожей архитектуре, но вместо Go-бота с MCP-серверами используем Telegram-топики как естественный диспетчер. Каждый топик = один проект = одна изолированная сессия Claude Code. Роутер определяет, какую модель подключить (Opus для сложного, Haiku для рутины), и каждая сессия видит только свой рабочий каталог.
Несколько наблюдений из опыта с ~100 параллельными сессиями:
CLAUDE.md >> промпт-инструкции в агенте. У нас в каждом проекте CLAUDE.md с архитектурой, правилами безопасности и деплой-инструкциями. Работает надёжнее, чем передача контекста между агентами, потому что файл всегда актуален и не теряется при компакции.
CHECKPOINT.md как замена передачи состояния. Вместо водопада контекста между саб-агентами, каждая сессия пишет своё состояние в чекпоинт. При перезапуске или смене контекста читает один файл вместо перечитывания всего проекта.
Код-ревью человеком: полностью согласен. Это единственное, что реально отделяет рабочий пайплайн от “лотереи”. У нас деструктивные операции (деплой, удаление, push) требуют явного подтверждения.
Интересно, что вы Claude Code гоняете на VPS. Мы тоже: Hetzner VPS + Windows + Telegram Router. Фоновые задачи действительно удобнее на сервере, чем на локальной машине.
Хорошая статья с реальными цифрами, а не абстрактными “повысили продуктивность на 300%”.
Могу добавить свои данные. У меня EdTech-платформа с 4M+ пользователей в год, и я перешёл на AI-assisted разработку примерно год назад. Ключевые наблюдения:
Экономия на рутине реальная, но не там, где ожидаешь. Максимальный эффект не от генерации кода, а от автоматизации операционки: контент-пайплайны, мониторинг, деплой-скрипты, парсинг документов. То, что раньше делал ассистент или джун, теперь делает агент.
Claude Code + грамотный CLAUDE.md в каждом проекте дал примерно 3-4x по скорости на типовых задачах. Но на сложной бизнес-логике может быть 1.5x или даже медленнее, потому что приходится проверять и переделывать.
Самое неочевидное: экономия пришла не от замены людей, а от того, что я как CTO перестал быть бутылочным горлышком. Раньше 10 задач в очереди, я один. Сейчас 100+ параллельных сессий Claude Code на разных проектах, каждая в своём изолированном контексте.
Про ваш расчёт 400K на ERP: с AI-assisted я бы оценил 250-300K, но не 150K. Потому что тестирование и интеграции (банки, 1С) всё равно ручная работа. ИИ не заменяет понимание бизнес-процесса заказчика.
Хороший хак. Мы тоже столкнулись с этой проблемой, когда стали гонять ~100 сессий Claude Code в день по разным проектам — контекст забивался чтениями файлов моментально.
Ещё один паттерн, который хорошо работает в дополнение: CHECKPOINT.md в корне проекта. Каждая сессия при завершении пишет туда своё состояние (что сделала, что дальше, какие файлы трогала). Когда контекст компактится или сессия перезапускается — Claude читает один файл вместо того, чтобы заново сканировать полпроекта.
По сути это тот же принцип — держать контекст чистым. Только Read(1-1) экономит на уровне отдельных правок, а чекпоинт-файл — на уровне всей сессии.
А code-index — это свой MCP-сервер для индексации? Или что-то другое?
Ага, конфирмейшн флоу закрывает вектор “выполни деструктивное действие”, но не “подмени контекст диагностики”. У меня было так: сервис писал в Event Log строку с текстом, похожим на имя другого сервиса. Claude начинал копать не в ту сторону. Пользователь видит связную гипотезу, проверяет её 20 минут, а проблема в другом месте.
Что помогает частично: санитизация логов перед передачей в контекст (strip unicode control chars, обрезка строк длиннее 500 символов) и structured output, когда модель обязана указать источник каждого факта. Если в выводе написано “согласно Event ID 7034 от svchost”, это можно верифицировать автоматически.
Понятно, что это не решает проблему полностью, но сужает окно атаки до случаев, когда инъекция мимикрирует под валидный лог. А так да, согласен, что в тестах это ловится только через adversarial-сценарии с заведомо отравленными логами.
Спасибо за разбор, всё по делу. Поправил:
Cookie подписан HMAC (SHA-256). Старый aa_uid с голым Telegram ID заменен на aa_session с подписью: user_id:expiry:hmac. Флаги HttpOnly, Secure, SameSite=Lax. Подделать без серверного секрета не получится.
Видео и субтитры убрал из публичной директории. Файлы перенесены за пределы webroot, раздаются только через PHP-гейт с проверкой подписанной сессии. Для платных уроков дополнительно проверяется оплата. Range-запросы для перемотки поддерживаются.
Секреты вынесены из исходников. Пароли Robokassa и ключи авторизации больше не в коде, лежат в файлах за пределами git.
paid-check.php оставил как есть , он и не должен быть барьером, только UX, как вы и написали.
По поводу HTTP/2: если речь про Rapid Reset (CVE-2023-44487), это на стороне хостинга, тем не менее тоже переделал.
Если захотите перепроверить, буду рад!
Подтверждаю из практики. Оркестрирую Claude Code через CLAUDE.md + system prompt, и самый большой прирост качества дал именно “контракт результата”, не промпт-инженерия.
Конкретный пример: промпт на генерацию постов для Telegram-канала. Было 1800 токенов с role-play, few-shot на 7 примеров и цепочкой CoT. Результат: модель копировала стиль примеров вместо обобщения.
Переписал в 200 токенов: жесткие ограничения (длина 800-1200 символов, максимум 1 эмодзи, конкретная структура), один пример формата, функциональная роль (“контент-редактор канала”). Качество выросло, а главное, стало стабильным.
Добавлю к выводам автора: с reasoning-моделями критично не только что писать в промпте, но и что убрать. Каждый лишний constraint модель честно пытается соблюсти, даже если он противоречит другим.
Подтверждаю из практики. Оркестрирую Claude Code через CLAUDE.md + system prompt, и самый большой прирост качества дал именно "контракт результата", не промпт-инженерия.
Конкретный пример: промпт на генерацию постов для Telegram-канала. Было 1800 токенов с role-play, few-shot на 7 примеров и цепочкой CoT. Результат: модель копировала стиль примеров вместо обобщения.
Переписал в 200 токенов: жесткие ограничения (длина 800-1200 символов, максимум 1 эмодзи, конкретная структура), один пример формата, функциональная роль ("контент-редактор канала"). Качество выросло, а главное, стало стабильным.
Добавлю к выводам автора: с reasoning-моделями критично не только что писать в промпте, но и что убрать. Каждый лишний constraint модель честно пытается соблюсти, даже если он противоречит другим.