Меня зовут Дмитрий, мне 42, из которых 19 я в IT. Я умею нанимать: как тимлид провёл около сотни собеседований, нанял полтора десятка разработчиков, знаю, как выглядит хорошее резюме со стороны стола.

А вот искать работу себе — не умею совсем. Моё резюме годами выглядело как «ну нормальное», отклики я отправлял раз в неделю, когда вспоминал, а сопроводительные письма писал в духе «здравствуйте, меня заинтересовала ваша вакансия». Знакомо?

Пару недель назад я поймал себя на мысли: весь поиск работы — это же чистая процессная возня. Мониторить вакансии, читать требования, сопоставлять со своим опытом, адаптировать резюме, писать письма, трекать статусы. А процессную возню в 2026 году умеет делать ИИ-агент. Ну я и нанял его. Бесплатно, правда, — он живёт у меня в терминале.

Это дневник первой недели: что получилось, где агент меня удивил и где сел в лужу.

Сетап, или как не отдать боту свою жизнь

Сразу про паранойю, потому что она тут уместна. Агент работает в моём основном браузере, в моих залогиненных сессиях — через расширение. Он открывает вкладки, читает страницы, кликает. Как ассистент, который сидит рядом и водит мышкой, пока ты пьёшь кофе.

Но ассистент с инструкцией. Я прописал ему три правила:

  1. Ничего наружу без моего «ок». Ни один отклик, пост или правка профиля не уходит сам. Агент готовит — я утверждаю.

  2. Только правда. Всё, что не подтверждено, помечается [УТОЧНИТЬ]. LLM обожает приукрашивать, а в публичном резюме врать нельзя вдвойне.

  3. Журнал. Каждый шаг записывается. Кто, что, когда, почему.

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

Что было сделано за неделю

Профиль. Агент разнёс моё резюме и LinkedIn: размытое позиционирование, пустая лента, фото нет. Подготовил новые тексты, контент-план постов. Фото сгенерировали нейросетью из моего реального селфи — отдельный квест: первые варианты я отверг с формулировкой «красиво, но это не я». Примерно как на собеседовании: технически всё верно, а не то.

Поиск. Раз в несколько дней агент собирает вакансии с разных площадок, скорит по моим критериям и приносит шортлист. Не «вот 40 ссылок, разбирайся», а «вот четыре, вот оценка соответствия каждой, и вот твои честные пробелы по каждой». Пробелы — лучшая часть. Он мне прямо пишет: тут у тебя нет нужного опыта, закрывать будем так-то. Жестко, но полезно — на собеседовании хуже будет.

Отклики. Три отклика отправлены, у каждого — персональное письмо под вакансию. По одному уже пришёл просмотр резюме от работодателя. Письма агент пишет лучше меня, и я это признал не сразу. Они конкретные, с цифрами, без воды. Потому что у него нет моей скромности и моей лени. Скромность в поиске работы, кстати, вредна так же, как и на собеседовании.

Контент. Один пост в LinkedIn опубликован, ещё три ждут моего ревью. Агент сам напоминает о них по расписанию — у него крон, как у взрослого. В понедельник в 10 утра он мне пишет: «пост готов, смотри». Ощущается странно: меня пинает робот, и это работает.

Что я понял за неделю

1. Самое дорогое в поиске работы — не интеллект, а регулярность. Собрать вакансии, прочитать каждую, сопоставить с собой, написать письмо — это вечер жизни. Агент делает это за 20 минут и приносит мне только решения: «на эти две откликаемся?» Вся моя роль свелась к «ок» и «не ок». Как у тимлида с хорошим джуном, только джун железный.

2. Человек нужен на входе и на выходе. Критерии формулирую я. Когда агент принёс мне вакансию, где надо руководить ERP-направлением, я сказал «нафиг», и он молча вычеркнул её и записал в журнал. Финальное «отправляем» тоже всегда моё. Всё между — его.

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

4. Площадки не любят ботов — и правильно делают. Поэтому агент работает через мой браузер и мои сессии. Это не «бот обходит капчу», это «ассистент кликает с моего разрешения». Разница важная: я в любой момент вижу, что он делает, и журнал никто не отменял.

5. Это продукт. К концу недели я поймал себя на мысли, что так выглядит сервис, за который люди платили бы деньги. Мы, айтишники, массово не умеем искать работу — и страдаем от этого больше, чем от легаси. Если у агента получится со мной, почему не сделать так для других? Сижу, прикидываю модель. Но это уже тема следующей статьи — если эксперимент выстрелит.

Что дальше

Гоняю эксперимент до оффера. Записываю всё: сроки, конверсии, сколько раз я сказал «не ок» и почему. Во второй части разберу методику — как агент скорит вакансии и пишет письма. В третьей, если дойдёт, — экономику сервиса карьерного агента.

А пока вопрос к вам: доверили бы вы ИИ откликаться на вакансии от вашего имени? И где граница — что в поиске работы точно должно остаться за человеком?

Комментарии (31)


  1. toxic_fox
    01.11.2026 17:06

    Очень интересно и да, я бы доверила ии агенту такую задачу


  1. antdantd
    01.11.2026 17:06

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


  1. powerman
    01.11.2026 17:06

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


    1. dima_kos Автор
      01.11.2026 17:06

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


      1. Hlad
        01.11.2026 17:06

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


        1. Kalash969
          01.11.2026 17:06

          Мне кажется "трагедия общинных земель" предполагает некую равнозначность акторов. Тогда как при найме соискатель и компания имеют кратно разные возможности.


          1. Hlad
            01.11.2026 17:06

            В данной ситуации работодатель - это не конкурент на общественном пастбище. Это само пастбище.


      1. Krenodator
        01.11.2026 17:06

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


  1. Tomasina
    01.11.2026 17:06

    Если агент получает от вас "не ОК", ему сообщается причина?


    1. dima_kos Автор
      01.11.2026 17:06

      Иногда он спрашивает почему, иногда ему очевидно. Я не говорил ему пока про критическое мышление, идея интересная, спасибо за вопрос.


  1. eugenk
    01.11.2026 17:06

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


    1. dima_kos Автор
      01.11.2026 17:06

      Начинал я с клодом, но прокатилась волна блокировок и перешел я на kimi, помимо этого локально крутятся несколько моделек, например для генерации картинок. Всё это работает на макбуке m4 pro max 36/1tb. Я, на самом деле, делаю большую ошибку что не изолировал агента в отдельном инстансе, а позволяю ему видеть всё что у меня есть, но другого железа для эксперимента брать не хочу. Может и зря, будущее покажет.

      Кстати kimi выпустили к3.1 и там открытые веса, но чтобы её запустить надо что-то около 2000гб ОЗУ, а так локально было бы круто иметь такого помощника.


      1. SabMakc
        01.11.2026 17:06

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


        1. dima_kos Автор
          01.11.2026 17:06

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


          1. SabMakc
            01.11.2026 17:06

            К сожалению у ИИ очень плохо получается сопоставлять важность задачи и степень прилагаемых усилий к ее решению. Но очень хорошо прокачано упорство. И это очень и очень опасная смесь. Он сам себе выдумывает проблемы, которые потом героически решает - даже если ценой станет система, на которой он запущен. Так что ограниченный доступ (или обособленное железо) - на мой взгляд, обязательное требование для запуска агента (+регулярный бекап).

            Для себя настроил так, что у агента в конейтнере доступа даже к ключам подписки нет (не говоря уже про SSH/GIT) - “навабкодил” проксю, которая подменяет Auth-заголовки на правильные )


            1. Krenodator
              01.11.2026 17:06

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


              1. powerman
                01.11.2026 17:06

                Это не совсем так. Если мягко. А если честно - то совсем не так. Докер изолирует инструмент, но рабочий каталог с текущим проектом остаётся общим с хостом, и "сбежать" из такой песочницы - элементарно. А само желание "сбежать" сформирует любая случайно залетевшая промпт-инъекция.

                Я разработал два более адекватных подхода: один через ssh в отдельного юзера, второй через изоляцию на Linux namespaces. Первый в теории можно и для мака портировать. https://github.com/powerman/sandbox-ai-dev


                1. SabMakc
                  01.11.2026 17:06

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

                  Если же к docker-контейнеру подключаться через SSH - то и особой разницы и нет.


                  1. powerman
                    01.11.2026 17:06

                    Не всё так просто. Откуда-то же внутри докера взялся каталог с проектом? Обычно - из файловой системы хоста. И для уязвимости не обязательно открывать проект в IDE хоста, зачастую достаточно просто зайти в этот каталог в шелле (из-за direnv, mise, etc.) или выполнить в нём git-команду (что триггерит хуки). А работать с проектом на хосте нередко есть необходимость хотя бы ради того, чтобы некоторые токены держать вне доступа ИИ (т.е. вне докера в нашем случае).

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


                    1. SabMakc
                      01.11.2026 17:06

                      Но если докер использовать как полноценную виртуалку, проекты в неё заносить через git clone и файлы с хостом не шарить - то да, будет безопасно. Просто очень неудобно.

                      Но чем это отличается от “другой пользователь” или “Linux namespaces” (через которые работает и docker)? Только тем, что вручную неудобно, а проект умеет?

                      Как минимум мне сценарий с docker нравится тем, что хост не загромождается средствами разработки - поверхность атаки ниже (хотя, конечно, от curl ... | bash это не спасет). И нет доступа к основной файловой системе - обычно на чтение там доступно много всего лишнего.

                      Конечно, можно все утилиты разработки держать в домашнем каталоге 2го пользователя и права настроить - но всегда останется сценарий “через уязвимость повысил права до root”. А в docker сбежать чуть сложнее будет.

                      P.S. а как с git работа идет? Ключи/пароли прописывать - даешь доступ к репо. Локально пушишь - натыкаешься на хуки. Через локальный git-сервер в 2 этапа пушить?


                      1. powerman
                        01.11.2026 17:06

                        Но чем это отличается от “другой пользователь” или “Linux namespaces”

                        Подход принципиально другой: в докере отличается ОС а файлы проекта общие, а в моих двух подходах ОС та же а файлы проекта разделены. Та же ОС даёт привычные инструменты и их конфигурацию, бесшовную интеграцию с десктопом - т.е. работаешь как обычно работал.

                        хост не загромождается средствами разработки

                        Если на хосте средств разработки нет, то ценность моего подхода сильно падает - он проектировался для ситуации, когда разработка велась именно на хосте и под неё уже всё настроено, а теперь нужно делать ту же разработку с использованием ИИ, и хочется сохранить привычное удобство работы не потеряв безопасность.

                        но всегда останется сценарий “через уязвимость повысил права до root”. А в docker сбежать чуть сложнее будет.

                        На самом деле это не так. Рут обычно даёт эксплоит ядра, а ядро в докере то же самое. Плюс дополнительно добавляются уязвимости самого докера. Так что в этом плане принципиальных отличий в безопасности между всеми этими вариантами нет, тут защиту даёт только виртуалка с другим ядром.

                        а как с git работа идет?

                        Как с любым коллегой. Песочница с ИИ рассматривается в этом плане как другой сотрудник: у него собственные токены и права доступа, обмен изменениями в репо с ним идёт через ревью и git push/pull после ревью изменений.


                    1. SabMakc
                      01.11.2026 17:06

                      В общем самый большой риск (помимо IDE или direnv) - это git-хуки. В целом решается достаточно просто (~/.bashrc):

                      export GIT_CONFIG_PARAMETERS="'core.hooksPath=/dev/null'"
                      

                      IDE - открывать, подключаясь к контейнеру (VS Code так умеет, лично я через SSH в контейнере работаю). Поверхность атаки сводится к контейнеру, локально только интерфейс.

                      direnv и подобное - просто не использовать. Если все средства разработки в контейнере живут - то он и не нужен на хосте.


                      1. powerman
                        01.11.2026 17:06

                        В том-то и дело, что этот подход не работает. Каналов утечек слишком много и постоянно придумывают новые. mise/direnv/хуки - их же придумали не для того, чтобы дыру в безопасности создать, а потому, что без них с проектом работать намного сложнее и неудобнее. Да и не всегда у вас есть возможность отказаться от использования хуков - они могут требоваться в рамках принятых процессов работы с проектом. С остальными утилитами та же фигня: иногда нужно работать с форками чужих проектов в которых они используются, т.е. полностью от них отказаться возможности нет.

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


                      1. SabMakc
                        01.11.2026 17:06

                        Подход “ИИ работает как коллега” требует или доступа ИИ к репо (под своим пользователем), или отдельного сервера git для обмена данными с ИИ.

                        Прямой доступ даже отдельным пользователем - сомневаюсь, что приживется в рамках командной разработки. Мало того, что каждому нужен 2й акк, так еще и внутренние обсуждения с агентом выходят за рамки локальной разработки.

                        Отдельно для ИИ поднимать какой-нибудь Gitea - идея тоже явно не лучшая. По крайней мере если до этого не стояло ничего подобного.

                        Хотя подход “у ИИ полностью изолированная среда, работа идет через Issue и MR” мне нравится. Но организационных моментов порождает много.


                      1. powerman
                        01.11.2026 17:06

                        Вы переусложняете. ИИ - ваш инструмент, поэтому доступ в репо (гитхаб/гитлаб/etc.) идёт под вашим аккаунтом, коммиты подписаны вашей подписью - в этом плане ничего дополнительного не требуется.

                        Что нужно дополнительно, так это возможность ограничить доступ для вашего аккаунта: отдельные токены для стейджа и прода, отдельные ключи ssh и т.п. Все эти токены/ключи для вашего аккаунта, но с разными правами - и в песочницу для ИИ прокидываются токены и ключи с минимальными правами доступа, не дающие ИИ случайно сделать то, о чём можно потом сильно пожалеть (напр. случайно грохнуть БД прода).

                        А что-то не прокидывается вообще. Напр. в моей реализации песочницы ключ для подписи коммитов остаётся на хосте (при вызове git commit в песочнице запрос пароля появляется на хосте).

                        В случае локальной разработки без центрального репо вроде гитхаба никто не мешает добавить git remote в репо на хосте на каталог с репо внутри ИИ-песочницы. Это позволит использовать те же git pull/push локально между двумя каталогами, что защитит от передачи на хост лишних "невидимых" файлов (хуки и настройки в .git, всякое в .gitignore) и позволит сделать git diff с веткой ИИ после git pull - т.е. ревью перед мержем в локальный каталог, по сути то же самое, что и при ревью PR на гитхабе.

                        В общем, единственный дополнительный организационный момент - это создание ограниченных ключей/токенов для работы ИИ под вашим же аккаунтом. Но это в любом случае нужно сделать, вне зависимости от используемого подхода к изоляции ИИ-агентов.


  1. maxidler
    01.11.2026 17:06

    Интересная тема, однако в "массовости" скорее всего споткнется. Автор наклепал что-то под себя. В реальном мире, с другими критериями/задачами эта штука встретит кучу несоответствий и породит кучу багов.

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

    Как агент справляется с разными уровнями несоответствия и личными пожеланиями расти вглубь/вширь/вверх?


    1. dima_kos Автор
      01.11.2026 17:06

      Спасибо за комментарий. Пока в первую неделю ничего не было от агента на тему роста и решения несоответствий, пока агент просто отсекает вакансии, которые сильно не подходят. А вот если есть небольшие несоответствия, то в письмах-откликах он об этом честно пишет. Например, коммерческой go разработки, как требуется в вашей вакансии, не было, но ... и дальше пытается убедить что это не проблема, бравируя моими устремлениями, целями и возможностями.

      Хотя смотрю план на неделю и вижу что на среду он мне запланировал какую-то сессию вопросов по определению моих софт и хард скиллов, а так же опыта в той или иной сфере. Посмотрим, пока это только начало.


  1. dshumov
    01.11.2026 17:06

    А промтом поделитесь? :)


    1. dima_kos Автор
      01.11.2026 17:06

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


  1. lopuxilo
    01.11.2026 17:06

    Удачи с поиском!


  1. Krenodator
    01.11.2026 17:06

    Идея превратить этот скрипт в полноценный SaaS-продукт точно найдет свою аудиторию на рынке) Люди реально ненавидят тратить часы на написание персональных сопроводительных писем