Спасибо за скриншот, нашел благодаря вам еще одну ошибку (хорошо, что тут обычная карта NOAA, её легко воспроизвести). Треугольники были багом в самом парсере: в двоичных данных иногда встречается байт, который формат ISO 8211 использует как конец поля, и парсер на нём останавливался. Из-за этого пропадала часть записей и обрывались списки координат, контуры замыкались длинными хордами. На этой карте терялась примерно треть объектов. Исправил, проверил на двух десятках карт NOAA разного масштаба, после обновления страницы (Ctrl+F5) залив должен выглядеть нормально, заодно появились глубины, которые раньше терялись.
Про масштабы вы пришли ровно к тому, как устроены официальные карты: ячейки делятся по назначению, от обзорных до причальных, и программа берет ту, что подходит к текущему зуму, а не отбирает объекты из одной огромной. Так что три комплекта это правильное решение, а не костыль 💪🏻
Пс: про навионикс - ваше дело, я просто не беру такие данные в сам проект.
Спасибо за подробный рассказ, путь через эмулятор и скриншоты впечатляет!
Про лишние линии: вы были правы, и это оказались две ошибки на моей стороне, обе уже исправил. Первая: вьюер обводил края зон там, где их обрезает граница данных ячейки, а по стандарту такие ребра не рисуются. Вторая: если внутренняя граница полигона (дырка) состояла из нескольких рёбер, я замыкал каждое ребро отдельно и получались прямые хорды поперёк. Обновите страницу, почистив кэш, должно стать заметно чище. Заодно вышла новая версия библиотеки в 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. Фоновые задачи действительно удобнее на сервере, чем на локальной машине.
Спасибо за скриншот, нашел благодаря вам еще одну ошибку (хорошо, что тут обычная карта NOAA, её легко воспроизвести). Треугольники были багом в самом парсере: в двоичных данных иногда встречается байт, который формат ISO 8211 использует как конец поля, и парсер на нём останавливался. Из-за этого пропадала часть записей и обрывались списки координат, контуры замыкались длинными хордами. На этой карте терялась примерно треть объектов. Исправил, проверил на двух десятках карт NOAA разного масштаба, после обновления страницы (Ctrl+F5) залив должен выглядеть нормально, заодно появились глубины, которые раньше терялись.
Про масштабы вы пришли ровно к тому, как устроены официальные карты: ячейки делятся по назначению, от обзорных до причальных, и программа берет ту, что подходит к текущему зуму, а не отбирает объекты из одной огромной. Так что три комплекта это правильное решение, а не костыль 💪🏻
Пс: про навионикс - ваше дело, я просто не беру такие данные в сам проект.
Спасибо за подробный рассказ, путь через эмулятор и скриншоты впечатляет!
Про лишние линии: вы были правы, и это оказались две ошибки на моей стороне, обе уже исправил. Первая: вьюер обводил края зон там, где их обрезает граница данных ячейки, а по стандарту такие ребра не рисуются. Вторая: если внутренняя граница полигона (дырка) состояла из нескольких рёбер, я замыкал каждое ребро отдельно и получались прямые хорды поперёк. Обновите страницу, почистив кэш, должно стать заметно чище. Заодно вышла новая версия библиотеки в 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. Фоновые задачи действительно удобнее на сервере, чем на локальной машине.