Меня зовут Дмитрий, мне 42, из которых 19 я в IT. Я умею нанимать: как тимлид провёл около сотни собеседований, нанял полтора десятка разработчиков, знаю, как выглядит хорошее резюме со стороны стола.
А вот искать работу себе — не умею совсем. Моё резюме годами выглядело как «ну нормальное», отклики я отправлял раз в неделю, когда вспоминал, а сопроводительные письма писал в духе «здравствуйте, меня заинтересовала ваша вакансия». Знакомо?
Пару недель назад я поймал себя на мысли: весь поиск работы — это же чистая процессная возня. Мониторить вакансии, читать требования, сопоставлять со своим опытом, адаптировать резюме, писать письма, трекать статусы. А процессную возню в 2026 году умеет делать ИИ-агент. Ну я и нанял его. Бесплатно, правда, — он живёт у меня в терминале.
Это дневник первой недели: что получилось, где агент меня удивил и где сел в лужу.
Сетап, или как не отдать боту свою жизнь
Сразу про паранойю, потому что она тут уместна. Агент работает в моём основном браузере, в моих залогиненных сессиях — через расширение. Он открывает вкладки, читает страницы, кликает. Как ассистент, который сидит рядом и водит мышкой, пока ты пьёшь кофе.
Но ассистент с инструкцией. Я прописал ему три правила:
Ничего наружу без моего «ок». Ни один отклик, пост или правка профиля не уходит сам. Агент готовит — я утверждаю.
Только правда. Всё, что не подтверждено, помечается [УТОЧНИТЬ]. LLM обожает приукрашивать, а в публичном резюме врать нельзя вдвойне.
Журнал. Каждый шаг записывается. Кто, что, когда, почему.
Вся «контора» живёт в git-папке: резюме, письма, дайджесты вакансий, журнал. Выглядит как рабочий репозиторий, по сути им и является — просто проект называется «найти мне работу».
Что было сделано за неделю
Профиль. Агент разнёс моё резюме и LinkedIn: размытое позиционирование, пустая лента, фото нет. Подготовил новые тексты, контент-план постов. Фото сгенерировали нейросетью из моего реального селфи — отдельный квест: первые варианты я отверг с формулировкой «красиво, но это не я». Примерно как на собеседовании: технически всё верно, а не то.
Поиск. Раз в несколько дней агент собирает вакансии с разных площадок, скорит по моим критериям и приносит шортлист. Не «вот 40 ссылок, разбирайся», а «вот четыре, вот оценка соответствия каждой, и вот твои честные пробелы по каждой». Пробелы — лучшая часть. Он мне прямо пишет: тут у тебя нет нужного опыта, закрывать будем так-то. Жестко, но полезно — на собеседовании хуже будет.
Отклики. Три отклика отправлены, у каждого — персональное письмо под вакансию. По одному уже пришёл просмотр резюме от работодателя. Письма агент пишет лучше меня, и я это признал не сразу. Они конкретные, с цифрами, без воды. Потому что у него нет моей скромности и моей лени. Скромность в поиске работы, кстати, вредна так же, как и на собеседовании.
Контент. Один пост в LinkedIn опубликован, ещё три ждут моего ревью. Агент сам напоминает о них по расписанию — у него крон, как у взрослого. В понедельник в 10 утра он мне пишет: «пост готов, смотри». Ощущается странно: меня пинает робот, и это работает.
Что я понял за неделю
1. Самое дорогое в поиске работы — не интеллект, а регулярность. Собрать вакансии, прочитать каждую, сопоставить с собой, написать письмо — это вечер жизни. Агент делает это за 20 минут и приносит мне только решения: «на эти две откликаемся?» Вся моя роль свелась к «ок» и «не ок». Как у тимлида с хорошим джуном, только джун железный.
2. Человек нужен на входе и на выходе. Критерии формулирую я. Когда агент принёс мне вакансию, где надо руководить ERP-направлением, я сказал «нафиг», и он молча вычеркнул её и записал в журнал. Финальное «отправляем» тоже всегда моё. Всё между — его.
3. Правда — это дисциплина, а не настройка. Агент честно ловит себя на приукрашивании, но только потому что я заставил его помечать всё сомнительное. Без этого правила первое же письмо было бы про «успешного лидера высокопроизводительных команд». Брр.
4. Площадки не любят ботов — и правильно делают. Поэтому агент работает через мой браузер и мои сессии. Это не «бот обходит капчу», это «ассистент кликает с моего разрешения». Разница важная: я в любой момент вижу, что он делает, и журнал никто не отменял.
5. Это продукт. К концу недели я поймал себя на мысли, что так выглядит сервис, за который люди платили бы деньги. Мы, айтишники, массово не умеем искать работу — и страдаем от этого больше, чем от легаси. Если у агента получится со мной, почему не сделать так для других? Сижу, прикидываю модель. Но это уже тема следующей статьи — если эксперимент выстрелит.
Что дальше
Гоняю эксперимент до оффера. Записываю всё: сроки, конверсии, сколько раз я сказал «не ок» и почему. Во второй части разберу методику — как агент скорит вакансии и пишет письма. В третьей, если дойдёт, — экономику сервиса карьерного агента.
А пока вопрос к вам: доверили бы вы ИИ откликаться на вакансии от вашего имени? И где граница — что в поиске работы точно должно остаться за человеком?
Комментарии (31)

antdantd
01.11.2026 17:06Что-то надо менять. Негоже специалистам такие сальто перед работодателем крутить. Надо бы чтобы работодатели так вертелись-то по идее...

powerman
01.11.2026 17:06Нынешние сложности с поиском работы не связаны с "процессом" и поэтому вряд ли исправляются таким подходом. Частично они вообще вызваны излишним использованием ИИ с обоих сторон (и в этом смысл Ваш подход можно даже расценить как подливание масла в огонь). Но если сидишь без работы и от безысходности, то так развлекаться однозначно лучше, чем просто страдать от текущей ситуации!

dima_kos Автор
01.11.2026 17:06Боты скоринг систем были еще и до ии-сумасшествия. Да и в целом не нужно страдать от ситуации, дали инструмент новый, значит используем его во благо себе. Работодатели внедряют ии в анализ резюме и чтение откликов по вакансиям, значит пусть мой агент с ними и разруливает.

Hlad
01.11.2026 17:06Это называется "трагедия общинных земель". Когда все видят, что использование ИИ убивает найм, но сами удержаться от этого самого использования ИИ не могут, потому что это в моменте даёт выгоду.

Krenodator
01.11.2026 17:06Битва двух алгоритмов, где один пытается впихнуть ключевые слова, а второй пытается их отфильтровать :)

eugenk
01.11.2026 17:06Забавная идея... Очень хотелось бы продолжения. Если не секрет, на каком железе это у Вас ходит ??? Сам сейчас подумываю о покупке чего-то, на чём такие штуки можно запускать локально.

dima_kos Автор
01.11.2026 17:06Начинал я с клодом, но прокатилась волна блокировок и перешел я на kimi, помимо этого локально крутятся несколько моделек, например для генерации картинок. Всё это работает на макбуке m4 pro max 36/1tb. Я, на самом деле, делаю большую ошибку что не изолировал агента в отдельном инстансе, а позволяю ему видеть всё что у меня есть, но другого железа для эксперимента брать не хочу. Может и зря, будущее покажет.
Кстати kimi выпустили к3.1 и там открытые веса, но чтобы её запустить надо что-то около 2000гб ОЗУ, а так локально было бы круто иметь такого помощника.

SabMakc
01.11.2026 17:06А так ли нужно другое железо? Агент неплохо себя и в docker-контейнере чувствует…

dima_kos Автор
01.11.2026 17:06Может и не нужно, конечно, но железо не резиновое. Если я запускаю llm для генерации 3д (есть у меня новое хобби по разработке игр), то можно просто уходить минут на 10, мак пыхтит как паровоз)

SabMakc
01.11.2026 17:06К сожалению у ИИ очень плохо получается сопоставлять важность задачи и степень прилагаемых усилий к ее решению. Но очень хорошо прокачано упорство. И это очень и очень опасная смесь. Он сам себе выдумывает проблемы, которые потом героически решает - даже если ценой станет система, на которой он запущен. Так что ограниченный доступ (или обособленное железо) - на мой взгляд, обязательное требование для запуска агента (+регулярный бекап).
Для себя настроил так, что у агента в конейтнере доступа даже к ключам подписки нет (не говоря уже про SSH/GIT) - “навабкодил” проксю, которая подменяет Auth-заголовки на правильные )

Krenodator
01.11.2026 17:06Изоляция в Докере без проброса лишних волюмов решает проблему безопасности процентов на 99

powerman
01.11.2026 17:06Это не совсем так. Если мягко. А если честно - то совсем не так. Докер изолирует инструмент, но рабочий каталог с текущим проектом остаётся общим с хостом, и "сбежать" из такой песочницы - элементарно. А само желание "сбежать" сформирует любая случайно залетевшая промпт-инъекция.
Я разработал два более адекватных подхода: один через ssh в отдельного юзера, второй через изоляцию на Linux namespaces. Первый в теории можно и для мака портировать. https://github.com/powerman/sandbox-ai-dev

SabMakc
01.11.2026 17:06Как понимаю, проблема не в docker, а в том, что локальная IDE на уязвимый проект "смотрит", что создает риски уже для хост-системы.
Если же к docker-контейнеру подключаться через SSH - то и особой разницы и нет.

powerman
01.11.2026 17:06Не всё так просто. Откуда-то же внутри докера взялся каталог с проектом? Обычно - из файловой системы хоста. И для уязвимости не обязательно открывать проект в IDE хоста, зачастую достаточно просто зайти в этот каталог в шелле (из-за direnv, mise, etc.) или выполнить в нём git-команду (что триггерит хуки). А работать с проектом на хосте нередко есть необходимость хотя бы ради того, чтобы некоторые токены держать вне доступа ИИ (т.е. вне докера в нашем случае).
Но если докер использовать как полноценную виртуалку, проекты в неё заносить через git clone и файлы с хостом не шарить - то да, будет безопасно. Просто очень неудобно. Потому что удобно настроено на хосте (где работали до появления ИИ-агентов), и дублировать все эти настройки в докере (и синхронизировать потом отличия с хостом) - идея так себе. Убирать с хоста и переносить всю работу внутрь виртуалки/контейнера - тоже неудобно, интеграция с десктопом хоста будет сильно хромать, и, фактически, придётся одновременно работать в двух разных ОС и поддерживать обе. Мой проект все эти проблемы решает.

SabMakc
01.11.2026 17:06Но если докер использовать как полноценную виртуалку, проекты в неё заносить через git clone и файлы с хостом не шарить - то да, будет безопасно. Просто очень неудобно.
Но чем это отличается от “другой пользователь” или “Linux namespaces” (через которые работает и docker)? Только тем, что вручную неудобно, а проект умеет?
Как минимум мне сценарий с docker нравится тем, что хост не загромождается средствами разработки - поверхность атаки ниже (хотя, конечно, от
curl ... | bashэто не спасет). И нет доступа к основной файловой системе - обычно на чтение там доступно много всего лишнего.Конечно, можно все утилиты разработки держать в домашнем каталоге 2го пользователя и права настроить - но всегда останется сценарий “через уязвимость повысил права до root”. А в docker сбежать чуть сложнее будет.
P.S. а как с git работа идет? Ключи/пароли прописывать - даешь доступ к репо. Локально пушишь - натыкаешься на хуки. Через локальный git-сервер в 2 этапа пушить?

powerman
01.11.2026 17:06Но чем это отличается от “другой пользователь” или “Linux namespaces”
Подход принципиально другой: в докере отличается ОС а файлы проекта общие, а в моих двух подходах ОС та же а файлы проекта разделены. Та же ОС даёт привычные инструменты и их конфигурацию, бесшовную интеграцию с десктопом - т.е. работаешь как обычно работал.
хост не загромождается средствами разработки
Если на хосте средств разработки нет, то ценность моего подхода сильно падает - он проектировался для ситуации, когда разработка велась именно на хосте и под неё уже всё настроено, а теперь нужно делать ту же разработку с использованием ИИ, и хочется сохранить привычное удобство работы не потеряв безопасность.
но всегда останется сценарий “через уязвимость повысил права до root”. А в docker сбежать чуть сложнее будет.
На самом деле это не так. Рут обычно даёт эксплоит ядра, а ядро в докере то же самое. Плюс дополнительно добавляются уязвимости самого докера. Так что в этом плане принципиальных отличий в безопасности между всеми этими вариантами нет, тут защиту даёт только виртуалка с другим ядром.
а как с git работа идет?
Как с любым коллегой. Песочница с ИИ рассматривается в этом плане как другой сотрудник: у него собственные токены и права доступа, обмен изменениями в репо с ним идёт через ревью и git push/pull после ревью изменений.

SabMakc
01.11.2026 17:06В общем самый большой риск (помимо IDE или direnv) - это git-хуки. В целом решается достаточно просто (
~/.bashrc):export GIT_CONFIG_PARAMETERS="'core.hooksPath=/dev/null'"IDE - открывать, подключаясь к контейнеру (VS Code так умеет, лично я через SSH в контейнере работаю). Поверхность атаки сводится к контейнеру, локально только интерфейс.
direnv и подобное - просто не использовать. Если все средства разработки в контейнере живут - то он и не нужен на хосте.

powerman
01.11.2026 17:06В том-то и дело, что этот подход не работает. Каналов утечек слишком много и постоянно придумывают новые. mise/direnv/хуки - их же придумали не для того, чтобы дыру в безопасности создать, а потому, что без них с проектом работать намного сложнее и неудобнее. Да и не всегда у вас есть возможность отказаться от использования хуков - они могут требоваться в рамках принятых процессов работы с проектом. С остальными утилитами та же фигня: иногда нужно работать с форками чужих проектов в которых они используются, т.е. полностью от них отказаться возможности нет.
Ну и кроме того, всё это создаёт проблему только если не контролировать изменения в проекте. Если ИИ работает на собственном клоне репо и изменения попадают на хост только после ревью и через git pull, то угроза безопасности падает до стандартного уровня "коллега запушил в репо фигню, которую пропустили на ревью и смержили". Потому что если пропустили и смержили, то не требуются mise/direnv/хуки, достаточно внедрить вредоносный код прямо в
scripts/test.shи его запустят на своих компах все другие разработчики.

SabMakc
01.11.2026 17:06Подход “ИИ работает как коллега” требует или доступа ИИ к репо (под своим пользователем), или отдельного сервера git для обмена данными с ИИ.
Прямой доступ даже отдельным пользователем - сомневаюсь, что приживется в рамках командной разработки. Мало того, что каждому нужен 2й акк, так еще и внутренние обсуждения с агентом выходят за рамки локальной разработки.
Отдельно для ИИ поднимать какой-нибудь Gitea - идея тоже явно не лучшая. По крайней мере если до этого не стояло ничего подобного.
Хотя подход “у ИИ полностью изолированная среда, работа идет через Issue и MR” мне нравится. Но организационных моментов порождает много.

powerman
01.11.2026 17:06Вы переусложняете. ИИ - ваш инструмент, поэтому доступ в репо (гитхаб/гитлаб/etc.) идёт под вашим аккаунтом, коммиты подписаны вашей подписью - в этом плане ничего дополнительного не требуется.
Что нужно дополнительно, так это возможность ограничить доступ для вашего аккаунта: отдельные токены для стейджа и прода, отдельные ключи ssh и т.п. Все эти токены/ключи для вашего аккаунта, но с разными правами - и в песочницу для ИИ прокидываются токены и ключи с минимальными правами доступа, не дающие ИИ случайно сделать то, о чём можно потом сильно пожалеть (напр. случайно грохнуть БД прода).
А что-то не прокидывается вообще. Напр. в моей реализации песочницы ключ для подписи коммитов остаётся на хосте (при вызове git commit в песочнице запрос пароля появляется на хосте).
В случае локальной разработки без центрального репо вроде гитхаба никто не мешает добавить git remote в репо на хосте на каталог с репо внутри ИИ-песочницы. Это позволит использовать те же git pull/push локально между двумя каталогами, что защитит от передачи на хост лишних "невидимых" файлов (хуки и настройки в .git, всякое в .gitignore) и позволит сделать git diff с веткой ИИ после git pull - т.е. ревью перед мержем в локальный каталог, по сути то же самое, что и при ревью PR на гитхабе.
В общем, единственный дополнительный организационный момент - это создание ограниченных ключей/токенов для работы ИИ под вашим же аккаунтом. Но это в любом случае нужно сделать, вне зависимости от используемого подхода к изоляции ИИ-агентов.

maxidler
01.11.2026 17:06Интересная тема, однако в "массовости" скорее всего споткнется. Автор наклепал что-то под себя. В реальном мире, с другими критериями/задачами эта штука встретит кучу несоответствий и породит кучу багов.
Однако в тексте видно несколько железных утверждений. Больше всего мне понравилось: мы не умеем искать себе работу. Есть такое - 102%! Другое - про несоответствия. Это более интересная тема. Всегда мы встречаемся с несоответствиями вакансии. Но важно ли это? Мы решали проблемы характера А. Сможем ли мы решить проблемы характера Б и В? Наверняка, если это проблемы того же уровня. Решить проблемы - в данном контексте может быть равно "закрыть задачи" - это не столь важно. Другой вопрос если это 1А против 2А или 3А. Так я обозначил проблемы/задачи другого уровня. Например: мы быстро и качественно кодим бизнес-логику, она на раз проходит тесты безопасности и нагрузочные тесты. Это уровень 1А. Уровень 2А - это когда у нас есть команда, входящая задача и ограниченные сроки, а проверки те же - тесты безопасности и нагрузочные тесты. Уровень 5А - когда есть бизнес задача, жесткий дедлайн, и требования к стабильности (они разложатся на безопасность и нагрузку), а так же требования к долгосрочной поддержке. И плюсом ко всему - ограничения бюджета. Вот тут несоответствие может сыграть бОльшую роль.
Как агент справляется с разными уровнями несоответствия и личными пожеланиями расти вглубь/вширь/вверх?
dima_kos Автор
01.11.2026 17:06Спасибо за комментарий. Пока в первую неделю ничего не было от агента на тему роста и решения несоответствий, пока агент просто отсекает вакансии, которые сильно не подходят. А вот если есть небольшие несоответствия, то в письмах-откликах он об этом честно пишет. Например, коммерческой go разработки, как требуется в вашей вакансии, не было, но ... и дальше пытается убедить что это не проблема, бравируя моими устремлениями, целями и возможностями.
Хотя смотрю план на неделю и вижу что на среду он мне запланировал какую-то сессию вопросов по определению моих софт и хард скиллов, а так же опыта в той или иной сфере. Посмотрим, пока это только начало.

dshumov
01.11.2026 17:06А промтом поделитесь? :)

dima_kos Автор
01.11.2026 17:06Я опытным путём пришел к тому что одного промта всегда недостаточно, я пишу цель, ввожу агент в режим рассуждения и дополняю его предложения. По итогу формируется что-то ввиде базы знаний и действий, которая постоянно корректируется мной и самим агентом. Другими словами самый первый промт был "я хочу чтобы ты нашел мне работу"

Krenodator
01.11.2026 17:06Идея превратить этот скрипт в полноценный SaaS-продукт точно найдет свою аудиторию на рынке) Люди реально ненавидят тратить часы на написание персональных сопроводительных писем
toxic_fox
Очень интересно и да, я бы доверила ии агенту такую задачу