Спасибо за подробный рассказ, путь через эмулятор и скриншоты впечатляет!
Про лишние линии: вы были правы, и это оказались две ошибки на моей стороне, обе уже исправил. Первая: вьюер обводил края зон там, где их обрезает граница данных ячейки, а по стандарту такие ребра не рисуются. Вторая: если внутренняя граница полигона (дырка) состояла из нескольких рёбер, я замыкал каждое ребро отдельно и получались прямые хорды поперёк. Обновите страницу, почистив кэш, должно стать заметно чище. Заодно вышла новая версия библиотеки в npm.
Файлы из Навионикса, пожалуйста, не присылайте: их лицензия запрещает извлекать и передавать данные карт, и тащить такое в открытый проект не хочу ни себе, ни вам 🙏🏻. Если лишние линии у вас останутся, пришлите просто скриншот и скажите, какие это объекты, этого хватит, чтобы разобраться.
Про qtVlm и тормоза на большом количестве ячеек: почти наверняка в сконвертированных данных нет атрибута SCAMIN, это минимальный масштаб, с которого объект показывается. Без него программа рисует все изобаты на любом зуме. В официальных картах ещё помогает разбивка ячеек по назначению (третий символ в имени ячейки, от 1 обзорной до 6 причальной): на мелком масштабе берется обзорная ячейка с редкими изобатами, на крупном подробная. Если проставить SCAMIN хотя бы изобатам и мелким объектам, qtVlm должен начать прятать их сам, тогда, по идее, и вычищать руками не придется.
Спасибо! Жёлтые точки, которые прыгали при зуме - действительно проблема. В таблице кодов объектов S-57 часть кодов была сдвинута, и кабельные зоны рисовались как буи, а символ площадного объекта ставится в центр видимой части, поэтому и скакал. Заодно нашлась такая же ошибка в кодах атрибутов, из-за неё все глубины красились одним цветом, а подводные камни не показывались. Сверил обе таблицы с каталогом IHO и закрепил тестами, теперь на Бостоне видны мели, осушки и камни.
Что ещё добавил по вашим замечаниям: легенду со знаками, которые есть на открытой карте (кнопка Legend или клавиша L), масштаб 1:N с линейкой и кратностью зума внизу слева, ограничение зума на 1:1000 и предупреждение, когда карта показана крупнее масштаба, в котором её снимали.
Кнопка Download в каталоге теперь тоже качает через зеркало, как Open, так что зависать на 16 КБ не должна. Обновите страницу с Ctrl+F5 и напишите, если что-то всё ещё не так.
Спасибо, по вашему совету уже поправил. Символы и подписи площадных объектов теперь ставятся в центр видимой части: на каждой смене вьюпорта полигон обрезается по экрану, центр считается по обрезанной фигуре, а если он выпадает наружу (вогнутый полигон или дырка), то берется середина самого широкого внутреннего отрезка. Для больших полигонов считаю по упрощенной геометрии, копия под каждый уровень масштаба с погрешностью около пикселя, и все это дело кэшируется. Лукап и приоритеты тоже теперь считаются один раз при загрузке ячейки. Правда сами условные процедуры у меня пока упрощенные, полноценные CSP с пересечениями (DEPCNT, OBSTRN, WRECKS, SOUNDG) ещё впереди, и тут ваш опыт очень пригодился бы.
Спасибо за подробный репорт, обе проблемы подтвердились и уже исправлены, можно проверить на том же демо (обновите страницу с очисткой кэша).
Были лаги из-за того, что вьюер перерисовывал всю карту на каждое движение мыши и каждый щелчок колеса, события копились в очередь, отсюда отставание на 15-20 секунд. Теперь во время перетаскивания и зума двигается готовый снимок карты, а полная перерисовка идёт один раз после того, как отпустили мышь. Сам рендер тоже ускорил примерно в два-три раза: объекты за краем экрана больше не рисуются, подготовка данных кэшируется, подписи раскладываются быстрее. Вроде должно лучше работать теперь.
И загрузку из каталога поправил: карты NOAA идут через прокси на Cloudflare, а его у части российских провайдеров режут, поэтому загрузка и вставала на 15 KB. Поднял второе зеркало вне Cloudflare. Если загрузка стоит 6 секунд без прогресса, вьюер сам переключается на него, а если не помогло и это, предложит скачать zip напрямую с NOAA и перетащить в окно. Прогресс теперь видно в килобайтах. Хотя вообще я не планировал делать браузер, но теперь вот придется допиливать))
Если что-то все ещё тормозит или не открывается, напишите, какая карта и что показывает строка статуса внизу, посмотрю. Спасибо!
Навионикс в S-57 это прям боль, там же своя модель данных, и все приходится перекладывать в объекты и chain-node топологию S-57. Самое неприятное, по моему опыту, это как раз топология и DDR в ISO 8211: файл вроде собирается, а читалка молча показывает пустоту.
Если хотите быстро проверить, что получилось, киньте свой .000 в демо: https://devladpopov.github.io/s57-parser/ Там сразу видно, собираются ли полигоны и не разъехались ли ссылки на геометрию. А если парсер на вашем файле сломается, пришлите, пожалуйста, мне такие кейсы как раз очень нужны для тестов.
Я тут не хотел связываться с навиониксом из-за лицензии: для себя на лодке ок, а выкладывать сконвертированные карты вроде уже нельзя.
А чем конвертируете? Через GDAL или пишете свой экспорт? И что пока самое сложное?
Спасибо, приятно встретить человека, который это уже проходил))
Контейнер тот же: S-101 тоже кодируется в ISO 8211, поэтому бинарный парсер у меня общий на оба формата. А вот модель данных вроде другая. S-101 построен на S-100: каталог объектов машиночитаемый (XML), а не зашит в спецификацию; атрибуты бывают составными и вложенными; есть отдельные типы информации; геометрия описывается кривыми и поверхностями вместо узлов и ребер chain-node.
Но, кжется, для вашей боли главное отличие в отображении. В S-52 условные процедуры описаны в спецификации псевдокодом, и каждый производитель переписывал их у себя руками, как вы и делали. В S-101 их заменил Portrayal Catalogue: правила отображения написаны на луа и поставляются вместе с каталогом, символы в SVG вместо HPGL, палитры отдельно. короче есть conditional rules теперь не нужно реализовывать, их нужно исполнять. IHO выкладывает этот каталог открыто на GitHub.
Ну а у меня условных процедур почти нет. Есть заливка DEPARE по DRVAL1/DRVAL2, пока с фиксированными порогами, а не от safety contour, и цвета и секторы огней. Проверок вроде “лежит ли OBSTRN над областью глубин меньше безопасной” нет совсем. Как раз обсуждаем в Discussions на GitHub переход на символы и правила из каталога S-101 с атласом, по той же схеме, что вы описали.
Ну и раз уж вы спросили, то мне интересно, как вы решали пространственную часть: заранее считали пересечения при загрузке ячейки или проверяли на лету через какой-нибудь индекс? Для браузера этот вопрос для меня сейчас в приоритете
Так поэтому все и расписал подробно. А то везде слышу только “установи 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С) всё равно ручная работа. ИИ не заменяет понимание бизнес-процесса заказчика.
Спасибо за подробный рассказ, путь через эмулятор и скриншоты впечатляет!
Про лишние линии: вы были правы, и это оказались две ошибки на моей стороне, обе уже исправил. Первая: вьюер обводил края зон там, где их обрезает граница данных ячейки, а по стандарту такие ребра не рисуются. Вторая: если внутренняя граница полигона (дырка) состояла из нескольких рёбер, я замыкал каждое ребро отдельно и получались прямые хорды поперёк. Обновите страницу, почистив кэш, должно стать заметно чище. Заодно вышла новая версия библиотеки в npm.
Файлы из Навионикса, пожалуйста, не присылайте: их лицензия запрещает извлекать и передавать данные карт, и тащить такое в открытый проект не хочу ни себе, ни вам 🙏🏻. Если лишние линии у вас останутся, пришлите просто скриншот и скажите, какие это объекты, этого хватит, чтобы разобраться.
Про qtVlm и тормоза на большом количестве ячеек: почти наверняка в сконвертированных данных нет атрибута SCAMIN, это минимальный масштаб, с которого объект показывается. Без него программа рисует все изобаты на любом зуме. В официальных картах ещё помогает разбивка ячеек по назначению (третий символ в имени ячейки, от 1 обзорной до 6 причальной): на мелком масштабе берется обзорная ячейка с редкими изобатами, на крупном подробная. Если проставить SCAMIN хотя бы изобатам и мелким объектам, qtVlm должен начать прятать их сам, тогда, по идее, и вычищать руками не придется.
Спасибо! Жёлтые точки, которые прыгали при зуме - действительно проблема. В таблице кодов объектов S-57 часть кодов была сдвинута, и кабельные зоны рисовались как буи, а символ площадного объекта ставится в центр видимой части, поэтому и скакал. Заодно нашлась такая же ошибка в кодах атрибутов, из-за неё все глубины красились одним цветом, а подводные камни не показывались. Сверил обе таблицы с каталогом IHO и закрепил тестами, теперь на Бостоне видны мели, осушки и камни.
Что ещё добавил по вашим замечаниям: легенду со знаками, которые есть на открытой карте (кнопка Legend или клавиша L), масштаб 1:N с линейкой и кратностью зума внизу слева, ограничение зума на 1:1000 и предупреждение, когда карта показана крупнее масштаба, в котором её снимали.
Кнопка Download в каталоге теперь тоже качает через зеркало, как Open, так что зависать на 16 КБ не должна. Обновите страницу с Ctrl+F5 и напишите, если что-то всё ещё не так.
Так победим 8)
Спасибо, по вашему совету уже поправил. Символы и подписи площадных объектов теперь ставятся в центр видимой части: на каждой смене вьюпорта полигон обрезается по экрану, центр считается по обрезанной фигуре, а если он выпадает наружу (вогнутый полигон или дырка), то берется середина самого широкого внутреннего отрезка. Для больших полигонов считаю по упрощенной геометрии, копия под каждый уровень масштаба с погрешностью около пикселя, и все это дело кэшируется. Лукап и приоритеты тоже теперь считаются один раз при загрузке ячейки. Правда сами условные процедуры у меня пока упрощенные, полноценные CSP с пересечениями (DEPCNT, OBSTRN, WRECKS, SOUNDG) ещё впереди, и тут ваш опыт очень пригодился бы.
Спасибо за подробный репорт, обе проблемы подтвердились и уже исправлены, можно проверить на том же демо (обновите страницу с очисткой кэша).
Были лаги из-за того, что вьюер перерисовывал всю карту на каждое движение мыши и каждый щелчок колеса, события копились в очередь, отсюда отставание на 15-20 секунд. Теперь во время перетаскивания и зума двигается готовый снимок карты, а полная перерисовка идёт один раз после того, как отпустили мышь. Сам рендер тоже ускорил примерно в два-три раза: объекты за краем экрана больше не рисуются, подготовка данных кэшируется, подписи раскладываются быстрее. Вроде должно лучше работать теперь.
И загрузку из каталога поправил: карты NOAA идут через прокси на Cloudflare, а его у части российских провайдеров режут, поэтому загрузка и вставала на 15 KB. Поднял второе зеркало вне Cloudflare. Если загрузка стоит 6 секунд без прогресса, вьюер сам переключается на него, а если не помогло и это, предложит скачать zip напрямую с NOAA и перетащить в окно. Прогресс теперь видно в килобайтах. Хотя вообще я не планировал делать браузер, но теперь вот придется допиливать))
Если что-то все ещё тормозит или не открывается, напишите, какая карта и что показывает строка статуса внизу, посмотрю. Спасибо!
О, круто, что кто-то этим занимается вживую))
Навионикс в S-57 это прям боль, там же своя модель данных, и все приходится перекладывать в объекты и chain-node топологию S-57. Самое неприятное, по моему опыту, это как раз топология и DDR в ISO 8211: файл вроде собирается, а читалка молча показывает пустоту.
Если хотите быстро проверить, что получилось, киньте свой .000 в демо: https://devladpopov.github.io/s57-parser/ Там сразу видно, собираются ли полигоны и не разъехались ли ссылки на геометрию. А если парсер на вашем файле сломается, пришлите, пожалуйста, мне такие кейсы как раз очень нужны для тестов.
Я тут не хотел связываться с навиониксом из-за лицензии: для себя на лодке ок, а выкладывать сконвертированные карты вроде уже нельзя.
А чем конвертируете? Через GDAL или пишете свой экспорт? И что пока самое сложное?
Спасибо, приятно встретить человека, который это уже проходил))
Контейнер тот же: S-101 тоже кодируется в ISO 8211, поэтому бинарный парсер у меня общий на оба формата. А вот модель данных вроде другая. S-101 построен на S-100: каталог объектов машиночитаемый (XML), а не зашит в спецификацию; атрибуты бывают составными и вложенными; есть отдельные типы информации; геометрия описывается кривыми и поверхностями вместо узлов и ребер chain-node.
Но, кжется, для вашей боли главное отличие в отображении. В S-52 условные процедуры описаны в спецификации псевдокодом, и каждый производитель переписывал их у себя руками, как вы и делали. В S-101 их заменил Portrayal Catalogue: правила отображения написаны на луа и поставляются вместе с каталогом, символы в SVG вместо HPGL, палитры отдельно. короче есть conditional rules теперь не нужно реализовывать, их нужно исполнять. IHO выкладывает этот каталог открыто на GitHub.
Ну а у меня условных процедур почти нет. Есть заливка DEPARE по DRVAL1/DRVAL2, пока с фиксированными порогами, а не от safety contour, и цвета и секторы огней. Проверок вроде “лежит ли OBSTRN над областью глубин меньше безопасной” нет совсем. Как раз обсуждаем в Discussions на GitHub переход на символы и правила из каталога S-101 с атласом, по той же схеме, что вы описали.
Ну и раз уж вы спросили, то мне интересно, как вы решали пространственную часть: заранее считали пересечения при загрузке ячейки или проверяли на лету через какой-нибудь индекс? Для браузера этот вопрос для меня сейчас в приоритете
Так поэтому все и расписал подробно. А то везде слышу только “установи 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С) всё равно ручная работа. ИИ не заменяет понимание бизнес-процесса заказчика.