Я построил себе ATS наоборот

В этот день api.hh.ru/vacancies перестал отвечать соискателям — публичный API закрыли, все запросы на список вакансий теперь 403. Для большинства это новость уровня «ну и ладно». Для меня это был тест на то, как устроена система, которую я к тому моменту уже собрал.

Контекст: я Senior Product Designer, искал работу. ATS — applicant tracking system — это машина, которая ранжирует тебя под вакансию: совпали ли ключевые слова, прошёл ли порог. Ты — строка в чьей-то воронке. Я построил обратное: систему, которая каждое утро ранжирует вакансии под меня. ATS наоборот. Источник правды — мой профиль, а не их JD.

Когда hh.ru закрыл API, я не чинил «парсер». Я менял один слой из трёх, не трогая остальные два. Про это и текст: не про то, что я автоматизировал поиск работы, а про то, как разделение источника правды и сменяемого AI-runtime делает систему устойчивой к тому, что внешний мир — и сами AI-инструменты — меняются под тобой каждые полгода.

Когда отвалился API, было два пути.

Первый — OAuth через dev.hh.ru. Зарегистрировать приложение, получить client_id/client_secret, гонять токены, обновлять их. Чисто, «правильно», как в учебнике. И — лишняя точка отказа, которую я не контролирую: завтра они меняют scopes или закрывают регистрацию, и я снова чиню инфраструктуру вместо того, чтобы искать работу.

Второй — RSS-лента hh.ru/search/vacancy/rss для списка плюс JSON-LD (application/ld+json, @type: JobPosting) на странице каждой вакансии для полного описания. Авторизация не нужна вообще. JSON-LD — это SEO-данные, которые hh.ru сам публикует для поисковиков; они стабильнее, чем парсинг DOM, потому что компания заинтересована их не ломать.

Я выбрал второй. Не потому что он «хакерский», а потому что у него меньше зависимостей от чужих решений. DOM-скрейпинг отбросил сразу — хрупко, ломается при первом редизайне. OAuth — как избыточную точку отказа под мою задачу. Файлы auth.py и setup_auth.py, написанные под старый API, стали мёртвым кодом. Это нормально: интеграция — расходник.

Вердикт простой. API, который тебе не принадлежит, — это не фундамент, это аренда. Строить на нём ядро системы — ошибка. Источники входных данных должны быть заменяемы по дизайну, а не по факту аврала.

Система разложена на три слоя, и это разделение — главное, что в ней есть.

Data Layer — Obsidian vault. Мой профиль, позиционирование, разбор ролей с trade-off'ами, предпочтения по зарплате и формату, журнал решений. SQLite с дедупликацией вакансий. Это источник правды. Он мой, он локальный, он переживёт любой инструмент.

Intelligence Layer — скоринг. Берёт вакансию и профиль, выдаёт fit-score 1–10, флаги, плюсы-минусы, рекомендацию. Тут живёт логика оценки: зарплата нетто ниже 180k — потолок 3 балла; требования явно под junior — потолок 4; явная культура JTBD — плюс балл. Это не «спросить у нейросети, что думаешь», это формализованные критерии из моего же профиля.

Runtime Layer — собственно AI, который крутит интеллект. И вот он — сменяемый. Сегодня это claude CLI. Завтра может быть что угодно.

Обычно, строя «AI-инструмент», сваливают всё в один слой: промпт, данные, логика и вызов модели спутаны в один скрипт. Тогда смена модели = переписать всё. У меня смена runtime не трогает ни данные, ни логику оценки. AI — это сменный интерфейс поверх моей системы знаний, а не сама система.

Это, если хочешь, тот же принцип, по которому хороший продукт отделяет состояние от рендера. Только здесь «рендер» — это языковая модель, а «состояние» — то, кто я и что мне нужно от работы.

Первая версия скоринга была на anthropic SDK с промпт-кэшингом через cache_control. Красиво по API. И требует отдельной платной подписки на API поверх той, что у меня уже есть в Claude Code.

Я переписал scorer на вызов бинарника claude через subprocess с флагом --print. Оплата идёт через подписку Claude Code, которая уже куплена. Отдельный ключ хранить и ротировать не надо. Минус красоты промпт-кэширования — плюс к тому, что инфраструктура не размножается. Для личной системы это правильный размен: меньше движущихся частей важнее академической чистоты вызова.

Дальше — батчинг. Вместо N вызовов по одной вакансии модель получает по 4 вакансии за раз и возвращает JSON-массив оценок: ceil(N/4) вызовов вместо N. Пауза 8 секунд между батчами, чтобы не упереться в rate-limit. 20 вакансий — это 5 батчей, а не 20 вызовов.

И самая показательная деталь. subprocess запускается с cwd="/tmp". Почему: claude CLI читает CLAUDE.md из рабочей директории. Если запускать из папки парсера, он подтягивает 5000+ символов системного контекста карьерного агента в каждый батч — промпт распухает, иногда роняет 300-секундный таймаут. Нейтральная директория без CLAUDE.md решает это одной строкой. Scorer'у не нужен весь мозг системы — ему нужен только профиль кандидата в системном промпте.

Это и есть тот инженерный слой, про который senior-дизайнеру обычно говорить «не положено». Но точка тут продуктовая: каждое из этих решений — про то, чтобы система работала каждое утро без меня, а не про то, чтобы я ей любовался.

Поверх всего — launchd-агент com.maximvechkitov.hh-brief.plist. Каждый день в 11:00 он запускает python3 run.py из папки парсера. LaunchAgent, а не LaunchDaemon — намеренно: агент работает в контексте пользователя, а значит может показывать уведомления. Демон от системного процесса этого на macOS не умеет.

Когда прогон закончен, прилетает нативное уведомление: «N вак. проанализировано · 🚀 X приоритет · топ Y/10 — название». Не Telegram-бот. Telegram я отбросил осознанно: бот, токен, chat_id, хранение секретов — всё это имеет смысл, только если нужен пуш на телефон в отрыве от компа. Парсер крутится локально на Mac в 11 утра, когда я и так за столом. osascript с нативным уведомлением — ноль setup'а. Ошибка уведомления обёрнута в try/except, чтобы не уронить парсер из-за косметики.

Время, кстати, не «оптимальное по науке» — изначально планировал 8:30, поставил 11:00 просто потому, что так удобнее мне. Систему строишь под себя, а не под чужой best practice.

Первый боевой прогон, 26 мая 2026: 154 вакансии с hh.ru → 55 прошли Python-фильтр (стоп-слова, зарплатный отсев, дедуп) → 55 из 55 оценены батч-скорером. Токены модели потрачены только на последнем шаге — всё, что можно отсеять бесплатно Python'ом, отсеяно до AI. Топ дня — 7.5 из 10. Не «вау-цифра». Честная.

Эту статью пишет не редактор. Её пишет Claude Code, читая мой vault — тот самый Data Layer. Профиль, журнал решений, исходники парсера, голос, в котором я хочу звучать. Переводы постов — тоже. Я не диктую текст, я держу источник правды актуальным, а runtime генерирует поверх него.

Это то же разделение, что и в скоринге вакансий. В одном случае система ранжирует вакансии под меня. В другом — пишет тексты от моего имени. Слой данных один и тот же: кто я. Слой runtime — сменяемый AI. Если завтра выйдет модель лучше — я меняю один бинарник, а не переписываю себя.

Вот вывод, ради которого всё это. «AI-native» — это не про то, сколько инструментов ты перечислишь в резюме. Это про то, есть ли у тебя источник правды отдельно от инструмента. Если твоё знание о себе, о продукте, о пользователе живёт внутри конкретного чата с конкретной моделью — ты не AI-native, ты заложник вендора. AI-native — это когда инструмент можно выдернуть и заменить, а система останется.

Я построил себе ATS наоборот не чтобы быстрее откликаться. Я построил его, чтобы проверить тезис на себе: источник правды — мой, AI — сменный. Сначала на собственном поиске работы. Потом на всём остальном.

Это не оптимизация поиска работы. Это продуктовое решение про то, кому принадлежит система.