Что дал AI-агент: цифры кейса и главный вывод
Три недели работы, 10 687 вакансий от 2 204 компаний, 1 127 открытых форм и 553 отклика, доведённых до кнопки «отправить». Итог - три собеседования, которые автор кейса прошёл. Разработчик выложил подробный разбор на Хабре и не стал приукрашивать результат: автоматизация доходит до определённой границы и там останавливается.
Граница видна в деталях. Фильтрация вакансий и оценка релевантности в этой системе идут без LLM, языковая модель подключается только для ответов на нестандартные вопросы форм. Капча и вопросы без канонического ответа обрывают автоматический сценарий, а экран «Спасибо за отклик» не подтверждает, что резюме дошло до адресата.
Ещё одна деталь, которая многое говорит о рынке: 96% отправленных откликов ушли всего в две системы, Greenhouse и Ashby. Остальные ATS в потоке встречались, но погоды не делали.
| Показатель | Значение |
|---|---|
| Собрано вакансий | 10 687 |
| Компаний в выборке | 2 204 |
| Открыто форм отклика | 1 127 |
| Откликов доведено до кнопки «отправить» | 553 |
| Назначено собеседований | 3 |
| Доля откликов в Greenhouse и Ashby | 96% |
| Срок работы системы | 3 недели |
Если считать конверсию в лоб, три собеседования на 553 отклика дают около 0,5%. Читать этот показатель стоит аккуратно: часть откликов, вероятно, не дошла, поэтому реальный знаменатель меньше, а конверсия выше. Обратная сторона тоже важна: 553 отклика это не результат ручного труда, а работа скриптов, и цена такого охвата измеряется часами разработки, а не часами кликов.
Архитектура AI-агента: три слоя автоматики между соискателем и работодателем
Между соискателем и живым человеком на стороне работодателя стоят три слоя автоматики. Первый - системы приёма откликов, они же ATS. Второй - защита этих систем от ботов: капчи, коды на почту, проверки на то, что форму заполнял человек. Третий - вопросы в форме, на которые нельзя ответить шаблоном. Автор кейса строил автоматизацию под первый слой, а сложности пришли из второго и третьего.
Поток данных выстроен линейно:
- сбор вакансий из открытых API досок и агрегаторов;
- фильтрация и оценка релевантности по формальным признакам;
- открытие формы отклика;
- заполнение полей и загрузка резюме;
- отправка и фиксация результата.
| Этап | Что делает система | Нужна ли LLM |
|---|---|---|
| Сбор вакансий | Запрашивает открытые адреса досок и агрегаторов, складывает вакансии в хранилище | Нет |
| Фильтрация | Отсекает нерелевантное по ключевым словам, локации, грейду и стеку | Нет |
| Открытие формы | Переходит на страницу отклика и разбирает структуру полей | Нет |
| Заполнение | Подставляет данные из профиля и резюме | Нет |
| Нестандартные вопросы | Формулирует ответ там, где шаблон не подходит | Да |
Почему LLM не нужна для фильтрации вакансий
Отбор вакансий идёт по формальным признакам, и это осознанное решение. Правила на словарях и регулярных выражениях отрабатывают за секунды и ничего не стоят, а прогон тысяч описаний через модель тянет деньги, время и добавляет неопределённость в результат. Оценка релевантности по ключевым словам скучна, зато предсказуема и легко отлаживается.
Набор критериев у каждого свой, но логика обычно такая: в описании есть нужные технологии, локация входит в разрешённый список, грейд совпадает, компания не в чёрном списке, стоп-слова не срабатывают. Автор кейса конкретный конфиг в опубликованном фрагменте не раскрывает, так что это типовой каркас, а не его настройки. Тот же принцип «сначала структурированный отбор, потом смысл» разобран в материале про SQL-подход к поиску вместо перебора всего подряд.
LLM подключается дальше по пайплайну, на последнем шаге: когда форма задаёт вопрос, для которого нет готового ответа в профиле. Такое разделение экономит токены и упрощает отладку: если вакансия отсеялась зря, вы правите правило, а не промпт.
Источники вакансий: открытые API досок и агрегаторы
Основа системы держится на простом факте: почти все компании держат вакансии в какой-то из систем найма, и у каждой такой системы есть открытый адрес, который отдаёт список вакансий обычным текстом. Ни логина, ни ключа, ни браузера не нужно. Это снимает главную боль сбора данных: не приходится парсить вёрстку и бороться с защитой.
Карта досок в кейсе выросла до 397 записей. Список собран автоматически, и каждая доска проверена живым запросом: адрес либо отдаёт вакансии, либо выбрасывается из карты.
| Система | Досок в карте |
|---|---|
| Ashby | 206 |
| Greenhouse | 139 |
| Lever | 42 |
| Workable | 9 |
| SmartRecruiters | 1 |
| Всего | 397 |
Одних досок мало. Агрегаторы Himalayas, Remotive, Jobicy, Arbeitnow и RemoteOK дают вакансии компаний, чьих досок автор не знает, и именно там находится половина вакансий, которую другим способом быстро не найдёшь. Плюс два потока: вакансии с Hacker News из ежемесячной ветки «Who is hiring» и русскоязычные Telegram-каналы с вакансиями.
Часть источников подключить не удалось, и это полезно знать, чтобы не тратить время на тупиковые ветки. Reddit без регистрации приложения отвечает отказом, у ai-jobs.net не нашлось публичного потока, с CryptoJobsList сбор настроить не получилось.
Как найти доски компаний через GitHub
Агрегаторы закрывают половину потребности, но не показывают компании с собственными досками. В описании кейса упоминается поиск по коду GitHub, и логика метода прозрачна: компании хранят в открытых репозиториях конфиги, документацию, внутренние утилиты и примеры интеграций, где встречаются упоминания их ATS.
Дальше схема такая. Вы ищете по коду строки вида greenhouse или ashby, отбираете репозитории компаний, вытаскиваете найденные адреса и прогоняете каждый живым запросом: отдаёт список вакансий или нет. Такая проверка обязательна, иначе карта быстро заполнится мёртвыми ссылками. Подход хорошо масштабируется: один удачный поисковый запрос даёт десятки новых досок, которых нет ни в одном агрегаторе.
Оговорка: конкретный набор запросов и скрипт автор кейса в опубликованном фрагменте не раскрывает, поэтому выше описана логика метода, а не воспроизведение его кода.
Почему 96% откликов ушли в Greenhouse и Ashby
Две системы доминируют и в карте, и в откликах. В карте на Ashby и Greenhouse приходится 345 из 397 досок, то есть почти девять из десяти адресов, а в отправленных откликах их доля доходит до 96%. Для практики вывод простой: автоматизацию логично начинать с этих двух ATS. Одна интеграция покрывает большую часть рынка, а Lever, Workable и SmartRecruiters добавляют остаток и требуют отдельных разборов форм.
Где автоматизация останавливается: капча, нестандартные вопросы и ложное подтверждение
Из 1 127 открытых форм до кнопки «отправить» дошли 553. Остальное прервалось, и в описании кейса приводятся две основные причины: 383 формы остановились из-за вопросов без канонического ответа, ещё 132 - из-за капчи. В опубликованном фрагменте статьи этот разбор не детализирован, поэтому цифры стоит читать как порядок величин, а не как точную статистику по каждому типу вопроса. Общий вывод от этого не меняется: узкие места лежат не в сборе данных и не в фильтрации.
Какие вопросы форм ломают автоматизацию
Канонический ответ существует для имени, почты, ссылки на резюме и вилки зарплат. Дальше начинается территория, где шаблон не работает: почему вы хотите работать именно в этой компании, опишите проект, где вы решали похожую задачу, как поступите в конкретной рабочей ситуации. Такие вопросы рекрутеры добавляют как раз для того, чтобы отсеять массовые шаблонные отклики.
LLM здесь подключается и генерирует ответ, но проблему это решает частично. Ответ должен опираться на факты из опыта конкретного человека, иначе получается гладкий текст без содержания. Плюс есть риск однотипности: если сотни откликов написаны по одной схеме, разница заметна при первом же прочтении. Практический вариант - держать базу фактов о себе (проекты, метрики, технологии) и подставлять её в промпт, а ответы на действительно важные вопросы писать вручную.
Почему экран «Спасибо за отклик» ничего не гарантирует
Успешная отправка формы и подтверждающий экран не доказывают, что отклик дошёл до системы работодателя. Сбой может случиться на стороне сервера, письмо с подтверждением попадает в спам, а часть ATS просто не присылает уведомлений. Единственный надёжный способ проверки - личный кабинет или письмо-подтверждение, если оно приходит; иначе отклик остаётся в статусе «отправлено, но не подтверждено». Для системы с автоматической отправкой это значит одно: в логах нужен отдельный статус доставки, а не только отметка о нажатии кнопки.
Как повторить кейс: компоненты и порог входа
Система собирается из понятных частей, каждая из которых решает одну задачу:
- доступ к открытым адресам досок: список вакансий отдаётся текстом, без логина и ключа;
- парсеры агрегаторов: Himalayas, Remotive, Jobicy, Arbeitnow, RemoteOK;
- хранилище вакансий на SQLite или Postgres с дедупликацией по компании и названию позиции;
- модуль фильтрации по формальным правилам, без обращения к модели;
- браузерный слой для работы с формами: Playwright, Selenium или аналог;
- LLM для ответов на нестандартные вопросы;
- логирование каждого шага: какие формы открылись, где прервалось, что ушло и с каким статусом.
Порог входа выше, чем кажется по описанию. Нужны уверенные HTTP-запросы, разбор JSON и HTML, работа с сессиями и куками, базовые навыки скриптинга. Большая часть времени уходит не на AI, а на разбор чужих форм, которые отличаются даже внутри одной ATS.
Риски тоже стоит учитывать до старта. Массовая автоматическая отправка нарушает условия использования некоторых досок, аккаунт или домен могут заблокировать, а поток однотипных откликов портит репутацию у рекрутеров, которые узнают шаблон с первых строк. Разумный старт - один ATS, узкий список компаний и базовая фильтрация; расширять карту имеет смысл после того, как схема стабильно проходит хотя бы десятки форм.
Что это говорит о найме в 2026 году
Кейс показывает асимметрию рынка. Соискатель собирает агента и отправляет сотни откликов, работодатель отвечает фильтрами, защитой от ботов и AI-скринингом. Конверсия около 0,5% при таком объёме выглядит закономерной: чем дешевле отклик для кандидата, тем строже фильтр на другой стороне.
Со стороны нанимающей компании это выглядит так: AI проводит интервью и оценку кандидатов без привязки к расписанию, а рекрутер получает готовый дашборд с баллами и транскриптами. Так устроен Amazon Connect Talent: интервью и оценка кандидатов идут потоком, а решение остаётся за человеком. Когда автоматизация работает с двух сторон, выигрывает не тот, кто отправил больше откликов, а тот, кто точнее попал в требования вакансии.
Итоги: кому подходит такой подход и какие у него ограничения
Схема окупается, если вы технический специалист и готовы писать код. Разработчик, тестировщик, аналитик или инженер с опытом работы с API соберут базовую версию сам, а дальше будут дорабатывать её по мере появления новых типов форм. Для нетехнических профессий порог входа выше, а отдача ниже: там больше весят сопроводительные письма и рекомендации, которые автоматизировать сложнее.
Ограничения стоит принять сразу. Капча и коды на почту требуют ручного вмешательства. Вопросы без канонического ответа обрывают сценарий. Подтверждение отправки остаётся неполным. Массовые отклики повышают риск блокировки и не добавляют шансов на этапе собеседования, где решение принимает человек. Похожая картина в разработке: агенты хорошо ускоряют рутину и почти не дают выигрыша там, где нужна новая логика и суждение, о чём подробно в разборе про AI-агентов в цикле разработки и иллюзию продуктивности.
Практический вывод из кейса простой: автоматизируйте сбор вакансий, отсев и заполнение стандартных полей, а на вопросах, которые влияют на решение рекрутера, оставляйте ручной режим. Начните с одной ATS, добавьте логирование статусов доставки и только после этого расширяйте карту досок.